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ABSTRACT 


Extravehicular  Activity  (EVA)  is  a  specialized  function  performed  during  spaceflights  in 
which  two  or  more  astronauts  don  spacesuits  to  perform  tasks  on  the  exterior  of  their 
spacecraft.  An  extensive  and  iterative  planning  process  is  required  to  prepare  for  each 
highly  choreographed  EVA  operation.  The  current  planning  process  relies  heavily  upon 
time-consuming  heuristic  approaches  by  subject  matter  experts  to  essentially  "hand- 
build"  each  EVA  plan.  This  research  develops  the  EVA  Planning  Model  (EPM),  a  linear, 
mixed-integer  program  intended  as  a  proof-of-concept  demonstration  for  employing 
formal  mathematical  optimization  techniques  to  EVA  planning.  The  EPM  is  thoroughly 
tested  to  verity  that  it  functions  as  intended  and  is  evaluated  by  expert  EVA  planners 
using  actual  task  infonnation.  We  find  that  the  EPM  proves  the  concept  that  formal 
mathematical  optimization  can  be  used  to  aid  in  subject  matter  experts  in  EVA 
development  and  planning.  It  is  particularly  useful  in  allowing  the  evaluation  of 
alternative  planning  inputs  and  thorough  assessment  of  EVA  plan  impacts  resulting  from 
external  changes. 
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EXECUTIVE  SUMMARY 


Extravehicular  Activity  (EVA)  is  a  specialized  function  performed  during 
spaceflights  in  which  two  or  more  astronauts  don  spacesuits  to  perfonn  tasks  on  the 
exterior  of  their  spacecraft.  Performing  an  EVA  involves  substantial  preparatory  costs  in 
tenns  of  severely  limited  resources  and  astronaut  crew  time.  EVA  operations  also  place 
the  participants  in  extreme  danger  from  a  multitude  of  sources.  As  a  result,  EVA  plans 
must  be  highly  choreographed  to  achieve  the  maximum  value  from  each  operation.  Since 
the  advent  of  EVA  capability  in  the  mid-1960s,  NASA  has  used  teams  of  extensively 
trained  and  experienced  subject  matter  experts  from  the  Mission  Operations  Directorate 
to  carefully  plan  these  activities.  They  undertake  an  elaborate  and  iterative  process  to 
transform  raw  requirements  from  the  program  customer  (currently,  the  International 
Space  Station)  into  a  highly  efficient,  executable  EVA  timeline. 

Given  the  evolutionary  development  process  and  repeated  re-working  of  the  plan 
required  throughout  the  planning  phase,  tools  that  can  assist  the  planning  experts  may 
result  in  significant  savings  or  enhanced  plan  quality.  We  develop  the  EVA  Planning 
Model  (EPM),  a  linear,  mixed-integer  program  intended  as  a  proof-of-concept 
demonstration  for  employing  formal  mathematical  optimization  to  EVA  planning. 

The  nature  of  EVA  planning  presents  us  with  a  difficult  challenge  in  terms  of 
proving  model  functionality  and  quality.  We  address  this  partly  by  introducing  a 
methodical  and  thorough  testing  regimen  derived  from  the  field  of  software  engineering 
and  adapted  to  our  mathematical  model.  The  proof-of-concept  culminates  with  the  use  of 
EPM  to  build  EVA  plans  using  actual  planning  data  from  subject  matter  experts.  Expert 
opinion  surveys  are  then  conducted  to  obtain  an  evaluation  of  the  concept  and  execution 
of  the  EPM,  its  usefulness,  strengths,  and  weaknesses. 

Our  assessment  of  EPM  and  the  survey’s  results  suggest  that  EPM  establishes  the 
basis  for  (and  warrants  further  research  on)  a  formal  mathematical  optimization  that  can 
be  used  to  aid  subject  matter  experts  in  EVA  development  and  planning.  EPM  creates 
credible  EVA  timelines  that  match  or  exceed  the  effectiveness  of  human  built  solutions, 


and  allows  for  trade-off  evaluation  and  "what-if '  scenario  analysis  that  can  be  valuable  to 
the  planning  community  in  a  variety  of  ways. 

The  EPM,  as  developed  in  this  research,  has  some  significant  limitations.  Among 
them  are  (1)  a  primitive  user  interface,  (2)  a  lack  of  functionality  in  several  important 
areas  (i.e.,  robotic  arm  integration  and  tool  constraints),  and  (3)  highly  variable  model 
performance  in  terms  of  solution  times.  We  recommend  future  improvements  that  can  be 
made  to  address  these  weaknesses  and  increase  the  model's  capabilities  and  usefulness. 
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I.  INTRODUCTION 


Extravehicular  Activity  (EVA)  is  a  specialized  function  performed  during 
spaceflights  in  which  two  or  more  astronauts  don  spacesuits  with  self-contained  life 
support  systems  (extravehicular  mobility  units  or  EMUs)  to  perform  tasks  outside  of  the 
spacecraft.  These  tasks  range  in  purpose  from  the  deployment  or  retrieval  of  scientific 
experiments  to  vehicle  maintenance  or  assembly.  The  standard  EVA  is  a  6.5-hour-long 
operation  (limited  by  EMU  consumables  and  crew  endurance)  in  which  two  crew 
members  perform  a  series  of  tasks  as  outlined  in  a  detailed  plan. 

Since  Ed  White  performed  the  first  U.S.  spacewalk  in  June  1965  (Portree  & 
Trevino,  1997),  the  National  Aeronautics  and  Space  Administration  (NASA)  has  made 
tremendous  advances  in  techniques,  support  equipment,  and  operations  related  to  EVA. 
The  construction  and  maintenance  of  the  International  Space  Station  (ISS)  has  relied 
heavily  upon  the  use  of  EVA.  To  date,  127  U.S.  EVAs  have  been  conducted  in  support  of 
the  ISS  assembly  and  its  on-going  mission.  The  design  of  the  vehicle  is  such  that  EVA 
operations  will  continue  to  be  a  frequent  and  critical  part  of  its  upkeep  for  the  life  of  the 
program,  projected  to  extend  to  between  the  years  2020  and  2028.  (NASA,  2010a). 

Though  NASA  has  leveraged  its  47  year  history  with  EVA  to  build  a  record  of 
overwhelming  success  throughout  the  ISS  program,  there  are  still  areas  with  potential  for 
improvement.  In  particular,  the  planning  of  EVAs  remains  a  very  labor-intensive  process 
which  relies  heavily  on  individual  expertise  and  multiple  iterations  between  different 
stakeholders.  In  effect,  each  EVA  is  hand-built  by  a  team  including  the  Mission 
Operations  Directorate  (MOD)  flight  controllers,  the  astronaut  crew,  and  the  EVA  Project 
Office. 

A.  HIGH  LEVEL  PLANNING  PROCESS 

The  normal  process  of  planning  an  EVA  takes  several  months  and  generally 
includes  the  considerations  discussed  in  the  following  subsections. 


1 


1.  Overview  of  the  Planning  Process 

There  are  several  phases  in  the  planning  process  from  conception  to  execution. 
Depending  on  the  program,  mission,  and  situation,  the  need  for  an  EVA  can  generally  be 
categorized  into  three  groups:  those  driven  by  a  single  high  priority  task,  those  composed 
of  a  collection  of  tasks  built  up  on  a  "to  do"  list,  and  those  necessitated  by  a  vehicle 
system  failure  or  other  contingency  situation. 

Once  a  need  is  identified,  the  customer  program  generates  requirements  (in  the 
form  of  tasks),  prioritizes  them,  and  organizes  them  into  their  best  estimate  of  EVA-sized 
groups.  These  requirements  are  evaluated  by  the  MOD  planners  who  create  draft 
overview  timelines  for  an  individual,  or  series  of  EVAs.  This  process  is  an  iterative, 
back-and-forth  exchange  in  which  the  planning  experts  generate  a  first  heuristic  timeline. 
Any  proposed  alterations  to  the  initial  allocation  or  prioritization  of  tasks  which  may 
have  an  impact  on  the  plan  must  be  negotiated  between  MOD  and  the  customer  program 
office. 

Once  a  basic  mapping  of  tasks  to  a  given  EVA  is  completed,  the  planners  will 
subdivide  and  order  tasks  to  maximize  efficiency  of  the  plan.  Many  considerations  are 
taken  into  account  in  this  process:  the  locations  of  tasks,  required  support  equipment, 
availability  and  location  of  spare  parts  and  tools,  translation  times  and  paths  from  one 
task  to  another,  astronaut  body  positioning,  lighting  conditions,  hazard  controls,  etc. 
These  considerations  result  in  a  draft  of  a  detailed  plan  which  has  a  high  level 
representation  called  a  summary  timeline.  When  this  is  developed,  the  astronaut  crew  is 
introduced  to  the  plan  and  training  begins. 

Although  the  activity  is  called  training,  it  is  equal  parts  practice  for  the  crew  and 
further  development  and  refinement  of  the  plan.  Several  facilities  are  utilized  in  this 
phase  of  development,  starting  with  basic  desktop  review  and  proceeding  to  the  more 
elaborate  Virtual  Reality  Lab  to  practice  fine,  close-up  work  and  spacial  relations. 
Simultaneously,  training  is  conducted  in  the  Neutral  Buoyancy  Lab  (NBL)  for  full  dress 
rehearsal.  The  active  response  gravity  offload  system  is  a  facility  that  helps  the  crew 
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practice  body  control  and  manipulating  masses  in  zero-gravity.  Other  training  aids,  such 
as  an  air  bearing  floor  and  camera  and  photo  labs  are  used  to  help  the  crew  practice  more 
detailed  facets  of  EVA. 

Throughout  the  training  phase,  the  EVA  timeline  is  constantly  refined  as  data  is 
gathered  on  the  duration  of  tasks  and  potential  issues  are  noted.  In  some  cases,  a  better 
understanding  of  the  time  duration  of  tasks  and  their  interactions  could  lead  to  the 
removal  or  addition  of  tasks  to  the  plan.  The  planners  are  constantly  gathering  data  from 
the  training  exercises  and  the  other  coordination  processes  that  are  concurrent.  There  is  a 
continuous  flow  of  detailed  requirements  related  to  interfaces,  hardware,  and  special 
constraints.  The  plan  is  filled  out  and  iterated  throughout  this  period. 

The  above  description  is  a  simplified  look  at  the  high  level  steps  in  the  planning 
process,  but  it  is  important  to  realize  there  is  much  more  complication  in  the  planning 
process  than  can  be  presented  here.  Many  layers  of  detail  underpin  the  creation  of  an 
executable  EVA  plan.  A  simple  example  of  the  increasing  levels  of  detail  considered  as 
the  plan  matures  is  what  the  planners  call  "bag-ology."  This  is  the  pseudo-science  of 
planning  the  contents,  packing,  use,  transportation,  deployment,  and  management  of  the 
storage  bags  the  crew  will  use  during  the  EVA.  Understanding  what  equipment,  tools, 
and  spare  parts  must  be  placed  in  bags,  how  and  when  they  will  be  used,  and  how  and 
where  they  can  be  temporarily  stowed  is  an  exhaustive  process.  It  alone  can  take  many 
hours  of  research,  development,  training  runs,  and  iterations  to  finalize.  Similarly  detailed 
work  is  required  to  incorporate  hazard  analysis,  orbital  replacement  unit  (ORU)  mass, 
center  of  gravity,  and  moment  of  inertia  data,  equipment  jettison  protocols,  tool  settings, 
tether  "tie  downs"  to  restrain  lose  equipment,  predicted  solar  radiation  conditions,  etc. 

The  final  phase  of  the  process  is  execution.  This  phase  is  the  most  time- 
compressed  and  dynamic.  Crew  performance  can  exceed  expectations,  creating  free  space 
to  accommodate  more  tasks,  or  problems  could  arise,  forcing  a  restructuring  of  the 
remainder  of  the  in-progress  EVA  or  of  subsequent  EVAs.  In-progress  re-planning  is  the 
most  time-critical  aspect  of  the  process  and  has  the  potential  for  the  most  gain,  but  also 
the  most  risk  in  tenns  of  opportunity  cost. 
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Figure  1  shows  the  basic  flow  of  the  planning  process.  This  thesis  is  concerned 
mainly  with  high-level  planning,  thus  many  of  the  intermediate  process  details  are 
omitted  from  the  flow  chart. 


Iteration  Iteration  Iteration 


Figure  1.  Simplified  EVA  Planning  Process  Diagram 


2.  Planning  Considerations 

Cost  is  a  primary  consideration  in  planning  an  EVA.  A  start-up  cost  results  partly 
from  the  need  to  physiologically  condition  the  crew  for  the  low  pressure,  100%-oxygen 
environment  of  the  EMU  suit.  Four  different  pre-conditioning  protocols  (called  pre¬ 
breathe)  have  been  approved  and  employed,  but  all  of  them  use  oxygen  and  nitrogen 
stored  in  high-pressure  tanks  aboard  the  ISS  and  a  significant  amount  of  crew  time 
(Brown  &  Jarvis,  2011).  Although  the  ISS  has  systems  to  recover  much  of  the 
atmospheric  gas  that  would  otherwise  be  vented  overboard  during  depressurization  of  the 
airlock,  the  air  that  is  not  recovered  is  a  factor  in  the  cost  as  well.  Gaseous  resources  like 
oxygen,  nitrogen,  and  air  must  be  fastidiously  conserved  aboard  a  long  duration  vehicle 
such  as  the  ISS  and  will  be  even  more  critical  on  any  future  deep-space  platform. 
Approximately  12  kilograms  of  oxygen  is  expended  from  the  ISS  high-pressure  gas  tanks 
for  each  EVA.  Crew  time  is  also  an  important  resource  aboard  the  ISS,  where  every 
minute  spent  on  systems  maintenance  or  tasks  like  EVA  preparation  takes  away  from 
time  devoted  to  scientific  experiments.  The  investment  for  pre -breathe,  which  is  in 
addition  to  the  time  required  for  tool,  equipment,  and  self-preparation,  can  range  from 

four  hours  for  the  "in-suit"  pre-breathe  to  an  overnight  "campout"  protocol  that  stretches 
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over  two  crew  days.  The  time  cost  is  also  very  significant  on  the  days  and  weeks  prior  to 
the  EVA.  Suit  checkout,  maintenance,  and  fit  verifications,  tool  preparation,  battery 
charging,  water  filtering,  and  planning  conferences  with  mission  control  add  significant 
time  as  well. 

It  must  be  considered  that  all  gaseous  consumables  used  for  EVA  preparation 
must  be  brought  to  Earth  orbit.  As  a  result  of  high  launch  costs,  estimated  by  the  U.S. 
House  of  Representatives  Subcommittee  on  Space  and  Aeronautics  at  approximately 
$20,000  per  pound  (NASA's  Commercial  Cargo  Providers,  2011),  these  resources,  along 
with  crew  time,  must  be  spent  very  wisely. 

Another  factor  in  EVA  planning  is  the  relatively  high  risk  of  these  operations.  The 
spacewalking  crew  is  working  in  the  most  hazardous  and  hostile  conditions.  Some  of  the 
risks  are  environmental,  such  as  the  vacuum  of  space,  extreme  temperatures,  radiation, 
and  micrometeoroid  and  orbital  debris  impacts.  Other  risks  are  occupational,  related  to 
the  work  and  equipment:  suit  snags  and  leaks,  entanglement,  hazardous  materials,  loss  of 
positive  contact  with  the  vehicle  or  tethers,  handling  massive  objects,  and  EMU  suit 
systems  malfunctions.  All  of  these  risk  factors  can  lead  to  serious  injury  or  death  for  the 
crew. 

These  costs  and  risks  drive  some  basic  guidelines  for  planning.  First,  all  EVA 
operations  are  planned  to  utilize  the  maximum  duration  of  EVA  time  and  minimize  the 
total  number  of  EVAs  to  accomplish  the  required  tasks.  Second,  all  time  outside  the 
vehicle  is  considered  precious  and  every  minute  must  be  planned  to  maximum  effect. 
Third,  all  EVAs  must  have  at  least  two  crew  members  to  allow  for  a  "buddy  system"  in 
case  of  emergency.  Additional  planning  considerations  are  employed  to  address  these  and 
other  costs  and  risks,  many  of  which  will  be  discussed  in  detail  in  the  planning  model 
formulation  presented  in  Chapter  II. 

3.  Special  EVA  Planning  Driver:  Big  12  Failures 

One  special  case  of  requirements  generation  shown  in  Figure  1  deserves  special 
attention.  Block  la  shows  that  EVA  requirements  can  be  driven  by  vehicle  systems 
malfunctions.  With  the  ISS  at  the  "assembly  complete"  phase,  one  of  the  biggest  drivers 
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for  EVA  is  the  potential  for  systems  failures  which  require  removal  and  replacement  of 
ORUs  on  the  exterior  of  the  vehicle.  The  ISS  program  has  identified  12  contingency 
EVAs  which  would  require  relatively  immediate  implementation.  Each  EVA  corresponds 
to  the  resolution  of  a  specific  ORU  or  functional  failure  aboard  the  ISS  and  this  list  of 
EVAs  (and/or  their  triggering  failures)  has  been  dubbed  the  "Big  12"  by  the  ISS 
operations  team  and  program.  Criteria  to  be  included  in  the  Big  12  is  formally  described 
by  the  ISS  program  as  "the  failure  of  the  function  provided  by  the  ORU  causes  a  situation 
placing  the  ISS  in  a  configuration  that  is  zero  fault  tolerant,  or  effectively  zero  fault 
tolerant,  to  survival"  (NASA  &  Roscosmos,  2011).  The  ability  to  handle  the  Big  12 
failures  via  EVA  repairs  is  such  an  important  concern  that  it  is  currently  one  of  the  top 
four  program  risks  identified  by  the  ISS  Program  Risk  Advisory  Board  (Uhran,  2012). 

Since  the  failure  modes  are  known,  these  EVAs  can  be  planned  to  a  basic  level 
ahead  of  time,  but  the  uncertainty  of  when  they  might  occur  drives  many  planning 
complications.  The  unknowns  are  many:  the  crew  members  who  will  perform  the  EVA, 
the  condition  of  the  vehicle,  the  status  of  supporting  equipment  and  systems  (such  as 
robotics),  any  secondary  schedule  drivers  (such  as  the  impending  arrival  of  a  resupply 
vehicle),  any  other  outstanding  tasks  that  could  be  added  to  a  Big  12  EVA,  etc.  The 
uncertainty  puts  tremendous  pressure  on  the  planning  process,  which  must  be  accelerated 
significantly  to  address  the  urgency  of  the  situation.  On  July  31,  2010  an  external  thennal 
control  pump  module  failed  aboard  the  ISS  (a  Big  12  failure),  driving  the  need  for  three 
contingency  EVAs  to  replace  it.  The  first  of  these  EVAs  was  executed  just  six  days  after 
the  malfunction,  the  second  and  third  followed  in  the  following  nine  days  (NASA, 
2010b).  Clearly,  such  an  intensive  sequence  of  operations  stresses  the  planning  process  in 
the  extreme. 

B.  SUMMARY  TIMELINE  DEVELOPMENT 

One  of  the  first  steps  in  the  planning  process  is  to  arrange  tasks  into  groups  that 
conceptually  represent  EVAs.  As  noted  in  Figure  1,  the  program  customer  begins  the 
process  by  identifying  tasks  and  assigning  relative  priorities  to  them.  The  program  then 
estimates  the  task  durations  and  produces  a  conceptual  EVA  which  is  simply  a  collection 

of  tasks  they  expect  will  fit  into  one  or  more  EVAs.  MOD  takes  this  input  and  applies  the 
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first  of  many  evaluations  to  its  feasibility  and  efficiency  by  creating  a  summary  timeline 
(sometimes  called  an  overview  timeline).  The  effort  required  to  produce  a  summary 
timeline  requires  approximately  one  week  for  one  to  two  experts.  It  is  the  basis  of 
iteration  in  the  planning  process  and  may  be  repeated,  in  part  or  as  a  whole,  several  times. 
This  iteration  is  essentially  an  education  and  negotiation  process  for  the  program 
customer  whereby  task  priorities  and  groupings  can  be  debated  on  the  basis  of  the 
efficiency  of  the  resulting  EVA.  This  process  continues  as  the  planners  work  through  the 
steps  in  Figure  1.  Often,  new  information  or  changes  late  in  the  process  can  lead  to 
renegotiation  with  the  program  customer,  resetting  the  process  back  to  a  very  early  stage. 
Thus,  many  summary  timelines  may  be  built  throughout  the  development  of  a  single 
EVA. 

Figure  2  shows  three  examples  of  summary  timelines  for  EVAs  that  have  either 
been  completed  or  are  in  the  planning  stage.  The  format  shown  is  one  of  several  used 
regularly  in  EVA  planning  and  will  be  used  throughout  this  research.  Two  rows  in  each 
graphic  represent  the  task  assignments  for  each  of  the  crew  members,  always  designated 
EV1  and  EV2,  respectively.  Phase  elapsed  time  (PET),  a  measure  of  time  that  begins 
when  the  crew  exits  the  spacecraft,  increases  to  the  right.  The  top  timeline  is  for  a 
nominal  EVA,  meaning  it  contains  tasks  which  are  driven  by  planned  program 
requirements  rather  than  a  need  to  address  equipment  failures.  The  second  timeline  is  for 
a  similar  nominal  EVA,  but  one  which  does  not  have  enough  tasks  to  fill  a  full,  6.5-hour 
EVA.  This  can  happen  if  there  are  not  enough  tasks  in  the  queue  when  an  EVA  is 
scheduled  or  because  the  planners  are  especially  concerned  that  some  tasks  could  take 
longer  than  planned.  As  a  result,  time  is  left  in  the  plan  for  so-called  "get-ahead"  tasks. 
This  allows  the  EVA  flight  controllers  to  slot  additional  tasks  into  the  extra  time  in  near 
real-time  as  long  as  the  scheduled  tasks  do  not  run  over  time.  The  third  timeline  is  for  a 
contingency  EVA,  one  that  would  only  be  performed  as  a  response  to  a  system  failure  or 
other  unplanned  event.  As  can  be  typical  for  this  type  of  EVA,  the  planned  tasks  do  not 
run  the  full  allowable  duration,  leaving  open  the  possibility  of  adding  other  tasks  to  the 
timeline  in  near  real-time. 
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The  remainder  of  this  section  elaborates  on  details  that  must  be  considered 


whenever  a  summary  timeline  is  generated. 
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Figure  2.  Examples  of  Summary  Timelines 
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1.  Task  Priority 

Generally,  tasks  will  be  ordered  in  an  EVA  timeline  with  deference  to  their 
priority.  Scheduling  the  highest  priority  tasks  first  gives  the  highest  probability  of 
completion  of  those  tasks  in  the  event  the  EVA  must  be  terminated  early  due  to  suit 
malfunctions  or  other  problems. 

There  are  cases,  however,  where  performing  a  lower  priority  task  first  creates  a 
valuable  time  efficiency  or  reduces  idle  time.  As  such,  the  schedule  cannot  be  driven  by 
priority  alone.  The  process  of  summary  timeline  creation  can  identify  situations  like  this 
which  usually  provide  useful  data  to  inform  a  renegotiation  with  the  program  customer  to 
ensure  they  understand  the  benefits  and  shortcomings  of  scheduling  tasks  strictly  in 
priority  order. 

2.  Task  Duration 

Each  task  is  assigned  an  estimated  duration  when  it  is  first  proposed.  Refining  this 
duration  is  one  of  the  goals  of  the  training  and  development  process.  This  refinement  has 
parallels  to  cost  estimation  in  a  normal  program  development  process.  In  some  cases,  the 
task  (or  a  similar  task)  will  have  been  perfonned  previously,  allowing  the  planner  to 
consult  a  database  of  actual  duration  information  for  a  specific  task.  As  each  task  is 
practiced  in  the  high  fidelity  simulators,  the  understanding  of  its  duration  is  improved 
further.  Lip  to  three  NBL  runs  are  dedicated  to  task  and  timeline  duration  validation  in 
nonnal  circumstances,  with  the  possibility  of  more  if  the  tasks  and  procedures  are 
immature  or  untried  (Brown  &  Jarvis,  2011). 

Once  enough  data  are  available  to  make  good  estimates  of  task  durations,  several 
modifying  factors  are  considered.  A  skill  rating  is  assigned  to  each  crew  member  based 
on  their  background,  experience,  and  aptitude  level.  This  rating  is  used  to  adjust  the  time 
required  for  tasks,  especially  in  cases  where  the  crew  perfonning  the  EVA  are  not  the 
same  astronauts  who  participated  in  the  ground  training.  Another  modifier  is  a 
multiplication  factor  applied  to  task  durations  derived  from  1-g  training.  Experience  has 
shown  that  tasks  simply  take  longer  when  performed  in  the  microgravity  environment  of 


10 


space  and  working  with  actual  flight  hardware.  Depending  on  the  task,  this  multiplier 
could  double  the  expected  time  to  complete  the  same  task  on-orbit  as  compared  to  1-g 
training. 


3.  Task  Location 

The  ISS  is  a  vast  structure  in  space  vehicle  terms.  It  is  roughly  the  shape  of  a 
cross,  with  a  109-meter  truss  extending  along  one  axis  and  a  51 -meter  axis  containing  the 
pressurized  modules  (NASA,  2011).  Practically  any  location  on  the  exterior  of  the  ISS 
could  be  an  EVA  worksite,  but  typically  worksites  will  be  centered  at  the  locations  of 
installed  equipment  (i.e.,  ORUs).  To  give  a  general  understanding  of  the  magnitude  of  the 
number  of  possible  worksites,  Figure  3  shows  the  locations  of  all  ORUs  installed  on  the 
truss  segment.  Each  red  circle  and  pointer  represent  one  installed  ORU  on  the  truss. 
There  are  many  more  worksites  on  the  exteriors  of  the  pressurized  modules  which  are  not 
shown  in  this  diagram. 
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Task  location  is  important  because  the  crew  must  move  from  worksite  to  worksite 
in  order  to  perform  their  jobs.  This  movement  is  typically  a  manual  "crawling"  from 
place  to  place  but  can  also  be  aided  by  the  robotic  arm.  Navigating  across  possibly 
sensitive  equipment,  avoiding  snag  hazards,  managing  body  position,  observing  proper 
tether  protocol,  and  ingress  or  egress  of  portable  foot  and  body  restraints  contribute  to  the 
time  required  to  move  from  one  location  to  another. 

4.  Task  Precedence 

Tasks  must  be  ordered  properly  to  comply  with  any  prerequisites  that  must  be 
completed  before  a  given  task  may  be  undertaken.  Precedence  relationships  between 
tasks  can  be  the  result  of  a  physical  need,  or  be  stipulated  by  the  planners  in  order  to  gain 
efficiencies.  An  example  of  the  former  is  disconnecting  electrical  connectors  before  a 
piece  of  equipment  can  be  removed.  In  the  latter  type,  planners  may  consider  operational 
reasons,  such  as  waiting  to  retrieve  a  replacement  part  until  the  old  one  is  successfully 
removed.  Otherwise,  if  unforeseen  problems  prevent  the  removal  of  the  old  part,  any  time 
spent  retrieving  the  new  one  will  have  been  wasted. 

5.  Task  Synergy 

Some  tasks  may  be  much  easier  or  quicker  to  perform  if  they  are  scheduled  either 
in  conjunction  with  or  following  other  specific  tasks.  For  example,  consider  a  task  which 
has  no  mandatory  predecessors,  but  would  take  50%  less  time  if  performed  following 
another  task.  Benefitting  from  this  type  of  efficiency  works  hand-in-hand  with  non¬ 
binding  task  precedence  as  described  in  the  previous  sub-section. 

6.  Special  Task  Timing  Requirements 

Some  tasks  have  special  timing  requirements  which  must  be  taken  into  account  in 
planning.  Some  examples  are: 

a.  Day/Night  Constraints 

The  orbital  speed  of  the  ISS  leads  to  a  unique  work  environment  in  which 
the  sun  rises  and  sets  every  90  minutes.  This  results  in  four  day  and  four  night  periods 
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during  the  typical  6.5-hour  EVA  and  has  an  effect  on  both  the  lighting  and  thermal 
conditions  that  can  impact  task  timing.  Some  tasks  can  only  be  performed  in  daylight  or 
only  in  shadow,  and  some  others  must  be  timed  such  that  they  do  not  cross  a  day-night 
boundary.  Fluid  connector  mate  or  de-mate  is  an  example  of  a  task  that  should  not  be 
performed  across  a  day-night  boundary  because  the  large  temperature  swings  can  cause 
"hydraulic  lockup"  of  the  connector  as  pressure  changes  inside  the  fluid  lines. 

b.  Thermal  Clocks 

Thermal  constraints  are  of  considerable  concern.  Most  electrically 
powered  exterior  ORUs  have  rigid  temperature  constraints  that  are  met  only  when  the 
equipment  is  powered  or  supported  by  heaters.  EVA  crews  routinely  have  to  remove 
power  from,  and  relocate  these  devices.  As  soon  as  power  is  removed,  a  so-called 
"thermal  clock"  begins  ticking  down  to  the  ORU's  lower  temperature  limit.  The  time 
window  allowed  before  power  must  be  re-applied  is  provided  by  engineering  analysis 
prior  to  the  EVA. 


c.  Support  Systems  Interaction 

Many  tasks  require  support  from  other  systems  on  the  vehicle.  Typical 
interactions  include:  de-energizing  an  electrical  bus  before  the  EVA  crew  disconnects  a 
wire,  stopping  the  rotation  of  the  moving  equipment  near  the  crew's  work  area  (such  as 
the  large  rotary  joints  that  point  the  ISS  solar  arrays  and  thermal  radiator  panels),  or 
deactivating  high  power  antennas  that  cause  a  radiation  hazard  to  the  crew  when  they 
enter  specific  areas.  Most  of  these  supporting  tasks  are  performed  by  the  crew  inside  the 
vehicle,  called  the  intra-vehicular  activity  support  crew,  or  by  flight  controllers  on  the 
ground.  In  either  case,  there  may  be  timing  constraints  on  performing  the  necessary 
supporting  actions  for  a  given  task. 

Some  support  system  interactions  could  impact  the  timeline  in  the  form  of 
wait  times.  For  instance,  a  new  segment  of  thermal  control  tubing  must  be  vented  of  its 
nitrogen  pad  before  being  connected  to  the  flight  system  for  the  first  time.  In  some  cases, 
the  crew  may  have  to  wait  for  this  process  to  complete  and,  in  other  situations,  it  may  be 

possible  to  continue  with  other  tasks  during  the  wait  period. 

14 


d.  Possibility  of  Suit  Contamination 

The  ISS  utilizes  several  highly  toxic  substances  in  its  systems.  This 
includes  pure  anhydrous  ammonia  and  hydrazine  propellants.  In  cases  where  the  EVA 
crew  must  interact  with  these  systems,  there  is  a  possibility  of  suit  contamination  from 
leaks.  If  an  EMU  suit  comes  in  contact  with  a  toxic  substance,  it  must  be  decontaminated 
before  it  comes  into  contact  with  the  ISS  cabin  atmosphere.  MOD  has  developed  a 
protocol  called  "bake-out"  which  is  performed  prior  to  airlock  ingress  and 
repressurization  in  cases  where  contamination  is  suspected.  Bake-out  requires  the  crew  to 
use  a  brush  to  remove  any  crystals  from  the  suit  and  then  expose  themselves  to  direct 
sunlight  for  a  predefined  period  of  time  to  heat  any  remaining  crystals  enough  to 
sublimate  off  the  suit.  This  is  a  fairly  lengthy  process  which  must  be  accounted  for  by 
scheduling  tasks  with  a  risk  of  toxic  contamination  early  enough  in  the  EVA  to  allow 
enough  time  for  its  completion  in  the  event  contamination  occurs. 

e.  Break  Out  Points  and  Bingo  Times 

For  tasks  that  could  leave  a  component  or  system  in  an  unsatisfactory 
condition  if  they  are  not  completely  finished,  breakout  points  are  identified  based  on  the 
specific  activities  involved  in  a  task  and  its  predicted  duration.  A  breakout  point  can  be 
thought  of  as  the  point  of  no  return  during  a  task:  a  decision  point  to  continue  or  abort  the 
task  based  on  how  much  time  is  left  in  the  EVA.  Tasks  which  cannot  be  segmented  in 
this  fashion,  but  carry  the  same  risks  if  not  completed,  are  assigned  so-called  "bingo 
times."  A  bingo  time  is  the  latest  point  in  the  EVA  where  the  task  can  be  started  and  still 
maintain  a  high  probability  of  completion.  Breakout  points  and  bingo  times  are  carefully 
evaluated  as  risk  trades  by  the  MOD  team  and  the  community  of  stakeholders. 

7.  Tandem  Tasks 

For  the  purposes  of  this  thesis,  we  consider  only  the  most  common  case  of  two- 
person  EVAs.  A  substantial  number  of  the  possible  tasks  that  could  be  assigned  during 
these  EVAs  require  both  crew  members  to  work  together.  The  need  for  two 
crewmembers  to  perform  a  task  can  be  driven  by,  for  example,  a  need  to  maneuver  or 
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hold  in  place  unwieldy  or  massive  equipment.  The  timeline  must  accommodate  both  crew 
members  being  in  the  correct  location  during  the  same  time  period  to  accomplish  tandem 
tasks. 


8.  Tool  Requirements 

Most  tasks  require  that  the  crew  use  one  or  more  tools.  Many  tools  have  been 
developed  for  use  by  EVA  crewmembers,  ranging  from  pry-bars  to  zero-torque  bolt 
drivers  and  cameras.  Deployment,  transport,  and  use  of  tools  are  important  factors  in 
EVA  planning.  Planners  must  ensure  that  the  crew  has  the  right  tools  packed  in  their  bags 
before  leaving  the  airlock,  that  tool  sharing  is  accounted  for  if  required,  and  that  tool 
movements  and  temporary  stowage  are  properly  handled. 

9.  Subdivision  of  Tasks 

Part  of  the  heuristic  nature  of  current  EVA  planning  is  in  the  subdivision  of  tasks. 
A  given  task  may  contain  one  single  objective  but  require  many  steps  to  complete.  These 
sub-tasks  are  not  strictly  defined  by  default  and  their  nature  may  be  optimized  by  the 
planner  throughout  the  development  and  training  process.  A  simple  example  of 
subdivision  can  be  observed  in  the  LEE  R&R  (Latching  End  Effector  Removal  and 
Replacement)  EVA  summary  timeline  (shown  as  the  third  timeline  in  Figure  2). 
Depending  on  how  detailed  the  program  customer  task  data  is,  the  planner  may  receive 
several  sub-tasks  or  just  one  task,  "Replace  Failed  LEE,"  as  an  input  for  this  timeline.  In 
the  case  where  few  detailed  tasks  are  given,  the  planner  must  subdivide  the  larger  tasks 
into  steps  which  can  then  be  planned  individually.  Examination  of  the  LEE  R&R  timeline 
in  Figure  2  shows  there  are  multiple  individual  tasks  identified  to  perform  the  objective 
and  demonstrates  the  level  of  subdivision  that  is  typically  done  by  the  planners. 

The  subdivision  may  be  based  on  any  number  of  factors  just  a  few  of  which 
follow.  Tasks  may  have  natural  break-points  that  could  be  used  to  subdivide  them,  such 
as  moving  to  a  new  worksite,  changing  tools,  or  altering  tether  points.  Other  drivers  may 
be  based  on  the  elimination  of  wait  times  that  could  be  part  of  larger  tasks  (for  instance,  if 
only  part  of  the  task  requires  two  crew  members). 
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C.  PROCESS  IMPROVEMENT  AREAS 

MOD's  flight  controllers  and  planners  often  find  themselves  in  the  position  of 
having  to  call  a  halt  to  a  seemingly  never-ending  string  of  minute  improvements  to  their 
plans  and  products  with  the  phrase  "better  is  the  enemy  of  good  enough."  Ultimately, 
they  are  preparing  for  events  that  will  happen  on  a  rigid  schedule.  Missions  and 
operations  will  not  wait  while  the  next  incremental  improvement  is  made.  In  this  light,  it 
is  difficult  to  claim  that  improvement  is  needed  with  respect  to  EVA  planning.  The 
success  of  currently  employed  methods  cannot  be  disputed.  NASA  has  approached,  and 
no  doubt  in  some  cases  achieved,  a  maximization  of  the  potential  of  each  EVA 
opportunity.  However,  we  believe  there  are  ways  to  improve  the  process  while  also 
making  it  faster.  Below,  we  detail  some  of  the  challenge  and  risk  areas  for  the  current 
process. 

1.  Cost,  Schedule,  and  Experience  Requirements 

The  process  described  in  Section  B  is  very  labor-intensive  as  every  step  in  it  is 
completed  by  hand.  This,  in  turn,  demands  highly  skilled  and  experienced  personnel.  The 
typical  EVA  lead  planner  from  MOD  has  five  to  ten  years  of  training  and  experience. 
This  caliber  of  engineer  is  a  very  costly  resource.  Additionally,  since  the  structure  of  the 
organization  is  such  that  the  same  group  of  people  perform  the  planning,  crew  training, 
and  all  other  stages  of  EVA  development,  there  is  a  zero-sum  game  aspect  to  work 
planning.  Any  off-loading  of  effort  from  the  highly  skilled  MOD  workforce  can  free 
them  up  to  perform  the  work  that  truly  demands  their  expertise.  In  other  words,  applying 
their  expertise  to  evaluating  plans  rather  than  drafting  them.  Developing  and  refining 
high  level  timelines  needed  every  time  tasks,  durations,  or  priorities  are  updated  could  be 
streamlined.  Automation  to  a  degree  that  can  allow  the  expert  to  focus  on  the  outcome 
rather  than  the  tedious  work  of  task  ordering  and  basic  constraint  de-confliction  would  be 
a  valuable  benefit.  Moreover,  as  the  process  involves  several  iterations  of  these 
development  phases,  the  payoff  of  automation  is  multiplied. 
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2.  Production  Speed 

As  a  corollary  to  the  labor-intensive  nature  of  current  EVA  plan  development,  the 
process  is  slow  to  navigate.  This  has  several  impacts  at  different  points  in  the  process. 
Early  on,  it  prevents  the  evaluation  of  many  different  timeline  options.  Later  in  the 
process,  it  restricts  the  ability  to  deal  with  late-breaking  changes  or  perturbations. 

There  is  constant  change  occurring  throughout  the  EVA  development  cycle, 
especially  as  it  relates  to  ISS,  a  continuous  mission.  This  change  can  take  the  fonn  of 
priority  changes,  new  tasks  being  added  to  a  plan,  other  tasks  being  deleted  (for  lack  of 
hardware  or  other  reasons),  or  even  change  of  crew  members  who  will  be  perfonning  the 
EVA.  Further,  support  equipment  can  fail  or  be  lost,  keep-out  zones  can  be  added  or 
changed,  or  changing  environmental  factors  such  as  solar  beta  angle  can  force  changes  to 
tasking  or  timing.  Some  of  these  factors  can  impact  an  EVA  just  days  prior  to  planned 
execution  (see  Section  II.E.2  for  a  more  complete  explanation  of  uncertainty  in  sunlight 
conditions). 

The  Big  12  EVAs  discussed  earlier  are  a  prime  demonstration  of  the  utility  of  a 
rapid  prototyping  capability  for  EVA  planning.  Even  though  the  pump  module 
replacement  conducted  in  2010  shows  that  the  current  process  is  capable  of  dealing  with 
such  situations,  the  ability  to  create  multiple  evaluation-ready  draft  overview  timelines  in 
minutes  or  hours  would  significantly  help  the  planning  team. 

Even  more  impactful  are  changes  that  occur  in  real-time  during  an  EVA.  Many 
times,  problems  with  a  task  early  in  an  EVA  may  prevent  the  completion  of  tasks  planned 
for  later.  Other  times,  the  crew  gets  ahead  of  the  timeline  and  there  may  be  free  time  that 
can  be  utilized.  The  MOD  team  does  plan  for  these  situations,  but  in  order  to  maximize 
the  efficiency  of  EVAs,  a  full  accounting  of  all  possible  changes  must  be  done.  There  is 
rarely  time  for  such  a  complete  examination.  Choosing  which  tasks  to  add  to  an  EVA  that 
is  ahead  of  schedule  or  delete  from  one  that  is  behind  is  hardly  done  haphazardly,  but  the 
decisions  could  be  more  infonned  if  basic  planning  decisions  could  be  tested  rapidly. 
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3.  Limited  Ability  to  Assess  Options 

Flowing  out  of  the  first  two  limitations  is  the  fact  that  only  a  small  number  of 
options  can  be  evaluated  for  a  given  EVA.  In  some  cases,  there  are  only  a  few  tasks  on 
the  program's  list  and  slotting  them  into  a  given  EVA  is  easily  done.  However,  in  cases 
where  there  are  more  tasks  than  could  fit  into  a  single  EVA  (or  multiple  EVAs  if  a  series 
is  being  planned),  the  experts  cannot  assess  all  possible  combinations  of  task  selection. 
Once  tasks  are  selected,  their  ordering  during  the  EVA  is  the  next  decision.  Once  again 
there  are  cases  where  this  is  self-evident,  but  also  many  where  discretion  can  be  applied. 
Even  a  relatively  limited  list  of  tasks  can  have  a  very  large  number  of  combinations,  far 
too  many  for  a  planner  to  investigate  comprehensively.  An  automated  tool  for  optimal 
task  selection  and  ordering  would  improve  the  quality  of  the  resulting  EVAs  by 
combining  the  two  decisions  into  one. 

In  summary,  such  a  tool  would  be  a  very  powerful  ally  in  negotiations  with  the 
program  about  task  prioritization  and  placement.  It  would  also  find  much  use  throughout 
the  iterative  process  of  plan  development  and  even  possibly  in  real-time  operations. 

D.  RESEARCH  GOALS 

The  goal  of  the  research  documented  in  this  thesis  is  to  investigate  the  feasibility 
of  utilizing  combinatorial  optimization  to  improve  the  efficiency  of  EVA  timeline 
development.  Specifically,  we  seek  improving  the  current  EVA  planning  process  in:  (1) 
the  time  required  to  develop  a  timeline,  (2)  the  thoroughness  of  trade-space  evaluation, 
and  (3)  the  verification  (or  simplification)  of  rule  and  constraint  compliance.  We  have 
introduced  the  planning  process  as  one  that  involves  substantial  effort  and  broad  scope.  It 
requires  much  in  the  way  of  individual  expertise,  experience,  and  hands-on  development. 
Our  goal  is  not  to  create  a  solution  that  nullifies  this  expertise,  but  rather  enhances  it  by 
alleviating  the  considerable  burden  of  developing  initial  timelines  and  by  allowing  the 
evaluation  of  many  more  potential  combinations  of  tasks  than  is  possible  today.  We 
further  intend  to  understand  how  useful  such  a  tool  might  be  throughout  the  planning 
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process  and  its  many  iterations  from  first  timeline  through  the  execution  phase.  Any 
examination  of  the  benefits  of  a  solution  must  also  investigate  its  limitations  and  we 
include  this  in  our  study  as  well. 

We  also  intend  that  by  focusing  our  solution  on  workload  reduction  for  the  EVA 
planners  rather  than  attempting  to  create  a  tum-key  plan  development  tool,  our  model 
will  meet  with  greater  acceptance  in  the  user  community.  This  is  critical  if  any  result  of 
this  research  is  to  be  pursued  to  assist  in  future  EVA  planning. 
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II.  EVA  PLANNING  MODEL 


This  chapter  details  the  development  of  the  EVA  Planning  Model  (EPM).  We 
begin  with  a  survey  of  some  classical  problems  and  techniques  in  the  operations  research 
literature  to  put  the  EVA  planning  problem  in  context  and  to  justify  our  approach  to  the 
problem.  Requirements  for  the  model  are  outlined  in  Section  C,  and  addressed  in  the 
EPM’s  formulation  developed  in  Sections  D  and  E. 

A.  MODEL  CONTEXT 

The  goal  of  the  EPM  is  to  create  the  optimum  EVA  plan,  which  to  the  first  order, 
is  the  one  that  maximizes  the  priority  of  scheduled  tasks  within  the  allowable  time.  The 
EVA  planning  problem  has  three  major  sub-parts:  selecting  which  of  the  available  tasks 
will  be  placed  into  the  timeline,  assigning  those  tasks  to  one  of  the  crew  members,  and 
ordering  the  tasks.  Clearly,  these  three  sub-problems  cannot  be  addressed  individually  in 
series  because  each  one  must  be  considered  with  respect  to  the  other  two.  We  must  also 
understand  that  priority  alone  does  not  dominate  the  decision  making  in  EVA  planning.  It 
coexists  with  efficiency  which  can  be  conceptualized  in  pseudo-units  of  priority  per  time 
unit  per  task. 

Solving  the  problem  of  translating  customer  requirements  (in  the  form  of  tasks 
and  relevant  task  data)  into  the  best  possible  EVA  timeline  can  be  informed  by  utilizing 
aspects  of  and  concepts  from  several  classical  combinatorial  optimization  problems  in  the 
operations  research  literature.  This  section  puts  the  EVA  planning  problem  into  context 
by  drawing  parallels  to  these  classical  problems. 

1.  Knapsack  Problem 

In  its  simplest  form,  the  knapsack  problem  assumes  a  given  a  set  of  items, 
j  e  {1,2,3 ,...«}  ,  where  each  item  j  has  a  value,  pj ,  and  a  weight,  w. .  The  problem  is  to 
determine  the  optimal  combination  of  items  to  maximize  the  total  value  which  can  be 
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carried  in  a  knapsack  of  limited  weight  capacity,  c .  Binary  variables,  x .  are  introduced 

to  indicate  whether  or  not  a  given  item  has  been  selected.  The  mathematical  formulation 
is  as  follows  (from  Martello,  1990): 

n 

Maximize  Z  =  ^  pjXj 
j= i 

n 

S.t.  YjWJXJ^C’ 

j= 1 

*,e{0,l},  y/ 

The  planning  drivers  for  EVAs  can  vary  as  discussed  in  Chapter  I.  In  situations 
where  the  goal  is  to  construct  the  best  possible  EVA  from  a  collection  of  prioritized  tasks 
identified  by  the  program,  task  selection  is  a  critical  part  of  the  solution.  The  knapsack 
problem  is  a  perfect  analogue  to  this  and  provides  us  with  a  guide  for  the  task  selection 
sub-problem. 

We  can  adapt  the  knapsack  problem  by  substituting  tasks  for  items,  priority  for 
value,  and  duration  for  weight.  Our  constraint  is  the  maximum  allowable  length  of  the 
EVA.  It  can  also  be  associated  with  a  situation  where  an  existing  EVA  timeline  has  some 
spare  time,  or  "white  space,"  available  and  we  must  select  from  amongst  a  group  of 
candidate  tasks  to  fill  it. 

This  adaptation  allows  us  to  use  the  knapsack  problem  formulation  as  a  base  upon 
which  to  build  our  task  selection  model.  We  must,  of  course,  still  concern  ourselves  with 
several  intricacies  of  task  selection  imposed  by  the  remaining  two  intertwined  sub¬ 
problems. 

2.  Travelling  Salesman  Problem 

The  travelling  salesman  problem  (TSP)  applies  so  naturally  to  a  variety  of 
business  and  travel  endeavors  that  it  has  been  contemplated  since  long  before  operations 
research  became  an  organized  field.  Published  non-mathematical  formulations  of  the 
problem  date  back  to  at  least  1832  (Schrijver,  2005).  As  summarized  by  Laporte  (2010), 
it  considers  the  problem  of  a  salesperson  whose  region  contains  n  cities  which  must  all 
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be  visited  exactly  once  before  returning  to  the  home  city.  The  goal  is  to  minimize  the 
total  travel  distance  or  cost  while  still  visiting  each  city.  The  problem  can  be  visualized 
more  easily  as  a  simple  network  graph  as  in  Figure  4.  The  distance  between  each  city  pair 
(i,  j)  is  denoted  by  L>  .  Travel  distance  is  equal  between  two  nodes  regardless  of  travel 

direction  and  all  nodes  are  connected.  The  path  taken  by  the  salesperson  through  this 
network  is  called  a  tour. 


Routing  is  a  major  factor  in  EVA  task  selection,  assignment,  and  scheduling 
because  the  ISS  is  a  large  structure  with  widely  distributed  worksites.  Since  each 
astronaut  must  physically  move  from  their  current  location  at  any  time  to  the  location  of 
their  next  assigned  task,  there  is  a  time  penalty  associated  with  scheduling  adjacent  tasks 
at  locations  separated  by  long  distances.  While  this  aspect  of  the  EVA  planning  problem 
is  a  textbook  instance  of  the  TSP  as  described  above,  it  has  several  considerations  that 
make  it  a  unique  variation  of  the  simple  TSP.  Figure  5  shows  a  network  model  more 
appropriate  for  the  EVA  case. 
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Figure  5.  EVA  planning  problem  as  an  asymmetric  TSP  network 

There  are  several  noticeable  differences  between  the  network  arrangements  in 
Figures  4  and  5  that  hint  at  some  of  the  complications  of  applying  TSP  methods  to 
optimizing  crew  movement.  Note  that  the  EVA  problem  includes  two  time  costs:  the  time 
to  move  (or  translate)  from  node  i  to  j ,  and  also  the  time  required  to  perform  the  task  at 
j  .  The  arc  costs,  TV ,  in  Figure  5  are  the  sum  of  these  two  costs.  Observations  about  the 
EVA  problem  as  it  relates  to  the  TSP  follow: 

(1)  Asymmetry.  The  EVA  network  in  Figure  5  is  asymmetric.  There  may  be  a 
different  cost  to  travel  between  two  nodes  depending  on  which  direction  is  traversed. 
This  is  because  the  EVA  case  is  expressed  in  units  of  time,  which  is  the  travel  "cost"  of 
the  EVA  planning  problem  (as  opposed  to  distance  or  money).  Even  if  we  ignore  the  task 
duration  caveat  noted  above  to  separate  translation  time  and  task  duration,  the  time 
required  to  travel  between  any  two  nodes  in  the  EVA  case  is  still  asymmetric.  The 
physical  translation  time  between  worksites,  which  may  or  may  not  be  aided  by  robot 
arm  support,  is  the  sum  of  the  movement  time  and  the  time  it  takes  for  the  astronaut  to 
properly  restrain  himself  at  the  new  location.  This  can  involve  setup  and  ingress  of  an 
adjustable  portable  foot  restraint,  configuration  of  a  body  restraint  tether,  or  a  number  of 
other  tasks.  Since  the  crew  support  interfaces  can  vary  by  worksite,  the  travel  cost  of  a 
given  arc  in  Figure  5  is  dependent  on  the  destination  node  and  thus  the  EVA  problem 
involves  an  asymmetric  TSP  (ATSP). 
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(2)  Dynamic  Nodes.  We  do  not  have  a  static  set  of  nodes  (worksites)  in  our 
network.  Worksites  are  associated  with  tasks  and  task  selection  is  part  of  the  overall 
problem.  If  we  stipulate  that  all  tasks  must  be  completed,  the  EVA  routing  sub-problem 
reduces  to  a  generic  ATSP  network,  but  we  need  to  allow  for  tasks  to  be  omitted  if  they 
are  not  part  of  an  optimal  solution  so  a  complete  network  does  not  exist  until  the  problem 
is  completely  solved.  Figure  5  depicts  this  with  the  dashed  node,  N  . 

(3)  Multiple  Agents.  We  have  two  crew  members  visiting  the  worksites  associated 
with  the  tasks,  thus  making  this  a  multiple  TSP,  with  the  additional  complication  that 
some  tasks  require  synchronization  of  both  crew  members.  Therefore,  the  goal  is  not 
simply  to  divide  all  the  worksites  or  tasks  among  the  two  crew  members  so  that  each  is 
visited  or  performed  once  and  only  once. 

(4)  Redundancy.  An  EVA  plan  does  not  restrict  repeated  visits  to  the  same 
location.  The  basic  travelling  salesman  problem  stipulates  that  each  node  (with  the 
exception  of  the  source  node)  be  visited  only  once.  This  constraint  is  not  appropriate  for 
EVA  for  various  reasons:  task  precedence  relationships  and  the  inclusion  of  tandem  tasks 
may  stipulate  that  a  worksite  be  visited  several  times.  Alternatively,  we  may  never  visit 
certain  worksites  or  perform  certain  tasks.  To  constrain  movement  (or  task  selection) 
such  that  each  worksite  must  be  visited  exactly  once  would  severely  limit  the  usefulness 
of  the  resulting  EVA  plans. 

(5)  Multiple  Task  Locations.  Although  an  EVA  plan  can  be  generally  visualized 
by  use  of  network  diagrams  as  in  Figure  5,  the  interweaving  of  tasks  and  locations  makes 
the  true  meaning  of  the  nodes  ambiguous.  Since  tasks  are  inherently  associated  with 
worksites,  a  node  could  ostensibly  represent  a  worksite  location  or  a  task;  however,  some 
tasks  occur  at  multiple  worksites  and  thus  a  crewmember  may  arrive  at  a  particular  node 
to  begin  a  task  and  leave  from  a  different  node  at  its  completion. 

(6)  Time  Windows.  Constraints  on  lighting,  interfaces  with  support  systems, 
ground  communications,  and  other  concerns  can  force  tasks  or  worksites  to  be  off  limits 
at  certain  times.  These  type  of  constraints  are  partially  represented  in  the  time-window 
variant  of  the  travelling  salesman  problem,  but  non-standard  specifications  of  those 
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constraints  are  required  in  the  EVA  case  as  will  be  discussed  later  in  this  document. 
Figure  5  denotes  the  existence  of  time  windows  with  dashed  arcs. 

(7)  Precedence.  Precedence  relationships  exist  between  many  tasks.  This  results  in 
what  amounts  to  a  combination  of  time  windows  but  the  restriction  extending  to  pairs  (or 
sequences)  of  nodes  rather  than  just  single  nodes. 

3.  Dynamic  Programming  Problem 

Imagine  the  EVA  sequencing  sub-problem  as  one  of  slotting  tasks  into  a  series  of 
stages,  k  e  {1,2,3,...|A|} .  This  conception  of  the  problem  is  depicted  in  Figure  6:  nodes 

represent  possible  tasks,  and  each  arc  has  a  transition  “cost”  equal  to  the  time  it  takes  to 
translate  from  one  worksite  to  another,  plus  the  time  it  takes  to  perform  the  second  task. 
Since  we  know  that  every  EVA  starts  with  airlock  egress  and  ends  with  airlock  ingress, 
those  nodes  are  fixed,  and  the  problem  aims  to  select  which  task  is  placed  into  a  given 
stage  in  order  to  create  a  sequence  that  minimizes  completion  time  of  all  tasks,  similar  to 
a  shortest  path  problem.  All  other  nodes  in  the  network  are  based  on  the  tasks  available 
and  are  a  result  of  the  task  selection  sub-problem. 


Stage  1  Stage  2 


Stage  3 


Stage  4  Stage  k 


Figure  6.  EVA  planning  problem  as  a  shortest  path  network  with  stages 


26 


It  is  worth  noting  that  the  EVA  planning  problem,  when  conceived  as  described 
above,  resembles  a  dynamic  programming  problem.  The  characteristics  of  these  problems 
(see,  e.g.,  Winston  (1987))  are:  (1)  the  problem  can  be  divided  into  stages  with  a  decision 
required  at  each  stage;  (2)  each  stage  has  a  number  of  states  associated  with  it;  (3)  the 
decision  made  at  any  stage  describes  how  the  state  at  the  current  stage  is  transfonned  into 
the  state  at  the  next  stage;  (4)  given  a  current  state,  the  optimal  decision  for  each  of  the 
remaining  stages  must  not  depend  on  the  previously  reached  states  (known  as  the 
principle  of  optimality,  see  Bellman,  1954);  and,  (5)  there  must  be  a  recursion  function 
any  stage,  k ,  and  state,  i ,  that  provides  costs  associated  with  the  next  stage,  k  + 1 . 
Figure  6  shows  that  we  are  able  to  divide  the  problem  into  stages  and  that  the  tasks 
(which  include  task  specifications  such  as  location,  duration,  etc.)  represent  the  states  for 
each  stage.  The  decision  of  which  arc  to  follow  from  each  state  defines  a  transition  to  the 
next  stage  and  state. 

However,  there  are  several  factors  that  make  the  actual  EVA  problem  more 
difficult  than  that  of  Figure  6.  The  first  complicating  factor  is  that  the  number  of  stages  in 
the  network  is  not  a  constant,  but  varies  based  partly  on  both  the  number  of  tasks  under 
consideration  and  their  durations.  Our  desire  to  allow  all  tasks  to  be  represented  as  states 
in  all  stages  of  our  network,  to  be  eliminated  from  subsequent  stages,  A'  +  l,  k  +  2,...K  ,  if 
selected  in  stage  k ,  would  violate  the  principle  of  optimality.  Each  stage  should  contain 
any  task  which  has  not  already  been  completed  (or  ruled  out  by  other  constraints  such  as 
task  precedence).  That  dilemma  also  threatens  the  possibility  of  creating  a  recursion 
function.  Finally,  additional  complications  arise  given  that  there  are  two  crew  members 
performing  tasks  simultaneously  during  an  EVA. 

4.  Job  Shop  Problem 

Among  the  classical  problems  in  operations  research,  the  job  shop  is  a  well- 
known  model  employed  for  sequencing  tasks.  This  section  discusses  the  basic  tenets  of 
the  job  shop  problem  and  its  application  to  EVA  planning. 
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a. 


General  Description  of  Job  Shop 


The  job  shop  problem,  is  primarily  a  scheduling  optimization  problem 
formulated  for  manufacturing,  production,  or  similar  operations  (see,  e.g.,  Nahmias 
(2009)).  The  generalized  setup  of  the  problem  is  a  manufacturing  floor  or  assembly  line 
with  machines  that  perform  actions  on  "jobs"  that  arrive  at  the  plant.  Jobs  have  a  duration 
(also  called  processing  time)  and  a  due  date.  This  results  in  a  need  to  identify  the 
sequencing  that  will  result  in  the  most  efficient  use  of  resources. 

b.  Static  and  Dynamic  Variants 

The  arrival  pattern  of  jobs  can  be  either  static  or  dynamic.  In  the  static 
scenario,  all  of  the  jobs  are  known  and  present  when  the  analysis  begins,  thus  the 
question  of  the  processing  order  is  simplified.  In  a  dynamic  scenario,  jobs  arrive  at 
intervals  throughout  the  analysis  period.  Arrivals  may  be  in  set  intervals  or  random  and 
based  on  a  probability  distribution.  In  the  dynamic  case,  the  job  shop  problem  takes  on 
the  characteristics  of  a  queuing  model.  More  randomness  can  be  encountered  if  the  job 
duration  is  not  detenninistic. 

c.  n  Jobs  on  m  Machines 

In  its  basic  form,  the  job  shop  problem  assumes  that  all  jobs,  n ,  arriving  at 
the  shop  will  be  processed  by  all  machines,  m  .  The  flow  pattern  of  jobs  can  be  dependent 
on  precedence  relationships,  machine  availability,  processing  times,  and  a  host  of  other 
considerations.  In  the  multiple  machine  case,  each  job  may  have  a  different  duration  for 
each  machine. 

A  special  case  of  the  multiple  machine  shop  is  one  in  which  some  or  all  of 
the  machines  are  interchangeable.  In  that  case,  any  job  can  be  processed  by  any  machine 
of  its  type  and  jobs  do  not  need  to  be  processed  more  than  once  by  identical  machines.  In 
that  situation,  minimizing  idle  time  on  the  machines,  called  line  balancing,  is  an 
important  consideration. 
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d.  Sequencing  Rules 

At  the  heart  of  any  job  shop  problem  is  the  selection  of  sequencing  rules. 
Nahmias  (2009)  identifies  the  following  commonly  used  sequencing  rules: 


(1)  First-come,  first-served.  Jobs  are  processed  in  the  order  they  arrive. 

(2)  Shortest  processing  time.  The  shortest  duration  jobs  are  performed  first. 

(3)  Earliest  due  date  (EDD).  Jobs  with  the  nearest  due  dates  are  perfonned  first. 

(4)  Critical  ratio  (CR).  A  critical  ratio  is  calculated  for  each  job  equal  to  the 
processing  time  divided  by  the  remaining  time  until  the  due  date  as  shown  in  the 
equation  below.  Jobs  with  the  highest  CR  are  performed  first. 

Processing  time 

C/  Tv 

Due  date  -  Current  time 

e.  Performance  Metrics 

The  measure  of  effectiveness  used  for  a  job  shop  solution  can  vary 
depending  on  its  goals.  Some  metrics  in  common  use  are: 

(1)  Flow  time  and  mean  flow  time.  Flow  time  is  the  total  time  to 
complete  a  given  job  from  its  entry  into  the  shop  to  its  exit.  Mean  flow  time  is  the 
average  of  the  flow  times  for  all  jobs. 

(2)  Makespan.  Measures  the  total  time  to  complete  all  jobs. 

(3)  Tardiness.  Calculated  as  the  difference  between  the  completion 
time  and  the  due  date.  A  positive  number  indicates  the  job  has  been  completed  after  the 
due  date. 


f.  Job  Shop  Applied  to  the  EVA  Planning  Problem 

Stripped  down  to  its  simplest  form,  the  EVA  planning  process  accepts 
tasks  as  inputs  and  produces  as  its  output  the  most  efficient  sequence  to  accomplish  those 
tasks.  Next,  we  point  out  some  significant  differences  between  job  shop  problems  and 
EVA  planning. 
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The  EVA  planning  problem,  conceived  as  a  job  shop,  is  formatted  as 
having  static  job  arrival  and  two  machines  (crew  members).  Since,  for  the  most  part,  any 
task  can  be  assigned  to  either  crew  member,  these  play  the  roles  of  interchangeable 
machines  performing  parallel  processing.  This  means  the  problem  can  be  viewed  as  two 
separate  single-machine  job  shops,  albeit  still  subject  to  line  balancing  considerations. 
The  situation  is  static  because  all  tasks  are  identified  up-front  and  so  a  time  dependent 
arrival  pattern  and  the  resulting  queue  are  not  a  factor.  The  result  of  these  characteristics 
is  that  for  the  EVA  problem,  the  focus  shifts  from  the  flow  of  tasks  into  and  through  the 
shop  to  the  task  allocation  of  the  machines. 

Another  change  in  focus  from  the  job  shop  problem  is  that,  in  EVA 
planning,  tasks  are  defined  by  their  priority  and  duration  rather  than  by  a  due  date.  As 
task  selection  and  assignment  are  both  variables  that  work  in  concert  with  sequencing, 
our  problem  differs  from  a  classical  job  shop  in  that  ours  does  not  force  all  tasks  to  be 
processed.  One  immediate  impact  of  these  subtle  differences  is  that  the  constraints  on  the 
problem  are  not  related  to  task  due  dates  but  rather  to  available  machine  time.  The 
standard  job  shop  time-to-completion  based  performance  metrics  of  makespan,  tardiness, 
and  flow  time  become  meaningless  for  a  single  EVA.  Task  due  date  and  the  time-based 
performance  measures  could  be  applied  to  a  system  designing  a  series  of  many  EVAs, 
but  the  primary  focus  of  this  thesis  is  for  single  EVA  planning. 

The  job  shop  problem  nonetheless  provides  a  basic  framework  for  the 
single  EVA  scheduling  problem.  In  particular,  we  intend  to  adapt  the  concept  of 
sequencing  rules  to  EVA  planning.  First,  we  must  understand  the  subtle  nature  of  the 
planning  goals,  two  of  which  can  be  stated  as  (1)  maximizing  total  task  priority,  and  (2) 
maximizing  priority  per  unit  time  during  the  EVA.  The  subtlety  of  the  second  goal  is  that, 
although  an  EVA  is  an  activity  of  known  duration,  the  task  priority  per  unit  time  should 
be  applied  as  a  running  value  throughout  the  EVA,  not  just  at  its  completion.  This  has 
great  importance  because  of  the  possibility  of  early  EVA  termination  or  delays  in  tasks 
early  in  the  timeline  which  may  force  tasks  nearer  to  the  end  to  be  skipped.  Both  of  these 
situations  are  outside  the  planner's  control  and  result  from  unexpected  events  or 
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problems.  Current  planning  heuristics  mitigate  these  risks  by  scheduling  high  priority 
tasks  as  early  as  possible  while  maintaining  overall  efficiency.  Any  credible  planning  tool 
must  address  these  considerations. 

The  above  discussion  suggests  the  EDD  sequencing  rule  is  a  valuable 
concept  when  applied  to  EVA  task  scheduling.  Task  priority  replaces  due  date  to  create  a 
new  sequencing  rule  based  on  EDD.  We  refer  to  this  as  "highest  priority  first"  (HPF). 
HPF  sequencing  would  result  in  scheduling  tasks  in  descending  priority  order,  which 
serves  the  purpose  of  rewarding  the  scheduling  of  higher  priority  items  earlier  in  the 
EVA.  HPF  cannot  be  the  final  word  on  task  sequencing,  however,  because  it  does  not 
account  for  task  duration  (or  the  many  other  limiting  constraints).  It  is  clear  that  to  ensure 
the  best  outcome,  task  duration  must  be  accounted  for  in  concert  with  priority.  To  help 
address  this,  we  can  borrow  again  from  the  job  shop  problem.  Adapting  the  concept  of 
the  critical  ratio  to  define  a  priority  ratio  (PR),  we  can  bring  task  duration  and  available 
time  into  the  fold.  The  PR  should  look  at  the  EVA  as  a  whole  to  divide  the  sum  of  all  task 
priority  values  by  the  total  available  time  (in  terms  of  PET): 

p^_  Total  Task  Priority 
Total  Available  PET 

A  combination  of  HPF  and  PR  can  be  used  to  create  an  EVA  which  has 
the  highest  overall  priority  value,  but  also  the  highest  priority  per  unit  time  throughout 
the  EVA. 


5.  Summary 

The  EVA  planning  problem  is  clearly  a  hybrid  of  many  common  problems  in 
combinatorial  optimization  and  the  operations  research  literature.  While  no  one  model 
approach  addresses  all  of  the  requirements  and  goals  of  the  EVA  problem,  aspects  of 
each  of  them  can  be  applied  to  assemble  a  combined  model  which  addresses  the  three 
sub-problems  of  task  selection,  crew  assignment,  and  task  sequencing.  Sections  C,  D,  and 
E  outline  those  needs  and  develop  the  EPM. 
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B.  OTHER  EVA  PLANNING  IMPROVEMENT  EFFORTS 

The  EVA  planning  process  has  long  been  understood  to  be  very  time  consuming 
for  the  planning  experts.  Attempts  have  been  made  to  address  this  by  applying  advanced 
automation  techniques  to  timeline  generation. 

1.  Prototype  Knowledge-based  EVA  Planning  System 

Notable  among  attempts  to  optimize  the  EVA  planning  process  is  a  previous 
master's  thesis  by  Bleisath  (1995),  then  a  member  of  the  EVA  planning  group.  That  work 
developed  an  automated  knowledge-based  tool  to  create  EVA  timelines.  The 
development  focused  on  the  scheduling  of  tasks  and  the  ease  of  use  of  the  resulting  tool 
for  the  planners.  It  represents  an  EVA  as  a  group  of  tasks  that  must  be  ordered  optimally 
without  addressing  the  question  of  task  selection.  Thus,  it  classifies  the  problem  as  a 
general  job  shop  problem  and  utilizes  heuristic  search  to  approximate  its  solution. 

Two  major  factors  drove  the  direction  of  that  research:  (1)  the  approach  had  to  be 
practicable  using  computer  power  that  was  severely  limited  compared  to  the  systems  in 
common  use  today,  and  (2)  it  was  undertaken  at  a  time  before  any  ISS  EVAs  had  been 
planned  or  executed,  and  so  did  not  have  the  full  benefit  of  experience  that  we  presently 
have  at  our  disposal. 

Due  to  the  limited  computer  resources  available,  formal  mathematical 
programming  was  not  considered  a  viable  option,  and  the  number  of  tasks  that  could  be 
scheduled  per  EVA  was  relatively  limited.  As  a  result,  the  tool  provides  a  somewhat 
limited,  high-level  output  for  EVA  task  sequencing  (although  it  produces  full  timelines 
and  includes  an  impressive  amount  of  detail  such  as  calculation  of  crew  movement 
speeds  in  various  configurations). 

The  model  has  a  limited  set  of  input  data  and  constraints  which  includes: 

•  Task  priorities 

•  Precedence  relationships 

•  Concurrence  relationships  (e.g.,  tandem  tasks) 

•  Manual  task  placement  (e.g.,  planners  have  the  ability  to  override  portions 
of  its  output  manually) 
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•  Assignment  of  specific  tasks  to  specific  crewmembers 

The  tool  developed  by  Bleisath  produces  impressive  results  but  has  not  been  in 
use  by  EVA  planners  due  primarily  to  its  omission  of  many  nuanced  constraints  which 
have  evolved  throughout  the  operational  history  of  EVA  on  ISS. 

Advances  in  computer  power  opens  the  option  of  utilizing  formal  mathematical 
programming.  In  addition,  the  wealth  of  operational  knowledge  from  15  years  of  ISS 
EVAs  has  allowed  us  to  understand  what  data  is  easily  available  and  how  major  tasks 
may  be  split  into  many  subtasks.  We  can  include  notably  more  detail  and  realism  in  our 
model  as  a  result  of  these  advantages. 

2.  Artificial  Intelligence  Based  Planning  Automation 

A  more  recent,  and  continuing  effort,  perfonned  by  TRACLabs,  Inc.  with  NASA 
funding,  investigates  the  automation  of  spaceflight  planning  from  a  wider  perspective. 
This  work  is  focused  on  automating  planning  for  all  disciplines  in  human  spaceflight, 
including  EVA.  Bonasso,  Boddy,  &  Kortenkamp  (2009)  utilize  an  EVA-centric  scenario 
to  serve  as  a  test  case  and  example  of  their  efforts  in  automated  mission  planning.  Their 
work  focuses  on  integrating  NASA's  in-development  procedure  representation  language 
with  artificial  intelligence  (AI)  based  planning  tools. 

A  fascinating  aspect  of  this  research  is  that  it  delves  to  a  much  lower  level  of 
detail  than  we  intend  to  do  with  EPM,  but  in  the  process  are  much  closer  to  possible 
solutions  to  the  sub-problem  of  task  sub-division.  Their  starting  point  of  using  existing 
procedures  to  develop  inputs  for  AI  planners  naturally  leads  to  a  focus  on  four  things:  (1) 
decomposition  of  tasks  into  smaller  parts,  called  hierarchical  task  nets,  (2)  assessing  the 
resources  associated  with  tasks,  (3)  thinking  of  tasks  in  terms  of  beginning  states  and 
ending  states,  and  (4)  understanding  the  interaction  between  actors  and  the 
interoperability  of  systems  involved  with  the  execution  of  tasks.  Figure  7  represents  a 
typical  hierarchical  task  net  developed  by  TRACLabs  to  decompose  an  EVA  task  called 
Remove  CETA  Light.  The  figure  highlights  the  differences  in  the  planning  level  of  EPM, 
which  considers  Remove  CETA  Light  as  a  single  task  needing  no  further  decomposition, 
to  the  high  level  of  task  dissection  performed  for  the  AI  planner. 
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Remove  CETA  Light 


Fetch  i  ravel  i  o  rcemt 

ORU  Bag  Work  Site  Light 


remove  Stow  Light  stow  Ljght 
Light  In  ORU  bag  |nside 


T  ravel 
To  A/L 


Stow  ORU 
Bag  i  n  A/L 


Travel  to  Tether  Travel  (si 
85' Tether  Swap  To  Work 


Travel  to  Tether  Travel(short) 

85'  Tether  Swap  To  A/L 


Figure  7.  Hierarchical  task  net  (from  Bonasso,  Boddy,  &  Kortenkamp  (2009)) 

The  ability  to  fully  model  the  interoperability  of  systems  and  the  interaction  of 
different  actors  in  the  performance  of  a  task  is  well  beyond  the  scope  of  the  EPM,  as  is 
the  focus  on  resources.  In  many  task  decompositions,  the  leaves,  or  lowest  level  of  the 
network  may  all  be  performed  by  different  actors  (flight  controllers,  EVA  crew  members, 
crew  members  inside  the  ISS,  etc.).  Further,  the  tracking  of  resources  is  very  meticulous, 
including  any  and  all  countable  resources  that  can  be  used,  consumed,  or  produced  by  a 
given  task.  For  the  EPM,  we  understand  time  and  tools  or  equipment  are  important 
resources  (although  tools  are  left  to  future  refinements  of  the  model),  but  do  not  attempt 
to  track  or  constrain  EMU  oxygen  levels  or  carbon  dioxide  removal  system  consumption 
as  the  automation  tool  does. 

In  the  actual  planning  of  EVA  activities  at  the  high  level,  the  EPM  employs 
optimization  to  select,  assign,  and  arrange  tasks  whereas  the  planning  system  currently 
utilized  by  TRACLabs  is  driven  wholly  by  heuristics  with  the  human  expert  planner  left 
to  do  any  optimization.  It  is  exactly  this  optimization  that  the  EPM  is  intended  to  aid  and 
thus  there  is  possible  synergy  between  the  two  efforts.  One  possible  collaboration  area  is 
in  sharing  of  the  task  database  and  resource  database  for  future  versions  of  EPM. 
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C.  MODEL  REQUIREMENTS 

This  section  outlines  the  basic  requirements  of  the  EVA  planning  model  including 
time  and  crew  limitations,  first  order  constraints,  and  outputs.  Any  requirements  which 
are  omitted  or  simplified  will  be  discussed.  The  subsequent  sections  describe  the  details 
of  the  included  requirements  and  show  how  they  are  being  addressed. 

1.  Basic  Summary  Timeline  Development 

The  EPM  must  accept  input  data  from  the  user  in  the  fonn  of  tasks  and  task 
attributes  and  output  a  summary  timeline  for  a  single  EVA  that  can  serve  as  a  basis  for 
evaluation  by  an  expert  planner.  Creation  of  this  timeline  necessitates  that  the  model 
selects  tasks  from  a  provided  list  and  orders  them  in  such  a  way  as  to  maximize  the 
priority  value  of  the  EVA.  The  model  should  then  allow  iteration  to  portions  of  the  plan 
that  do  not  meet  customer  or  operational  needs  while  holding  the  satisfactory  part  of  the 
plan  steady. 

EPM  output  can  be  the  basis  for  further  evaluation,  development,  and  training,  as 
in  Figure  1,  or  as  supporting  material  for  negotiations  with  the  program  customer 
regarding  task  priorities  and/or  expectations  of  task  allocation  to  specific  EVAs. 

2.  Task-Specific  Conditions 

The  model  should  account  for  the  conditions  and  special  circumstances  identified 
in  Section  I.B  when  generating  EVA  timelines.  Subdivision  of  tasks  and  task  synergy  are 
not  part  of  the  model  requirements  at  this  time.  The  insight  and  intuition  necessary  to 
perform  these  functions  is  beyond  the  scope  of  a  first-generation  planning  model. 
Certainly,  though,  the  model  can  still  aid  a  planner  in  subdividing  tasks  by  providing 
optimal  timelines  throughout  the  process  and  making  the  impacts  of  any  subdivisions 
more  obvious. 
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3.  Crew-Specific  Adjustments 

The  model  should  account  for  differing  crew  skill  levels  and  the  desire  to  assign  a 
specific  crewmember  to  a  specific  task  for  any  number  of  reasons  (e.g.,  higher  training  or 
experience  level). 

4.  Omissions 

Although  identified  as  important  aspects  of  EVA  planning,  the  EPM  does  not 
currently  address  tool  constraints  or  subdivision  of  tasks  (and  as  a  result,  break-out 
times).  Neither  is  task  synergy  incorporated  in  the  model.  These  capabilities  involve 
significant  complication  well  beyond  the  other  rules  and  constraints  handled  currently  by 
the  EPM. 

D.  INPUTS 

The  EPM  accepts  inputs  in  the  form  of  text  files  produced  using  templates  in 
Microsoft  Excel.  These  files  and  the  data  they  contain  are  described  below.  All  sample 
files  shown  are  from  the  LEE  R&R  contingency  EVA,  the  summary  timeline  for  which  is 
shown  in  Figure  2. 

1.  Task  Data 

For  each  task,  the  model  requires  the  following  data: 

•  Task  name 

•  Task  priority  (in  "value"  units,  where  higher  values  indicate  higher 

priority) 

•  Task  duration  if  perfonned  by  EV1  or  EV2  (in  minutes) 

•  Task  bingo  time,  if  required  (in  minutes) 

Each  task  also  has  a  set  of  binary  flags  ( 1  if  true  and  0  if  false)  associated  with  it 
to  indicate  whether  or  not: 

•  Task  is  mandatory 

•  Task  requires  both  crewmembers  (tandem) 

•  Task  carries  the  risk  of  toxic  fluid  contamination  on  the  EMU  suit 

•  Task  has  a  limited  set  of  legal  time  windows 
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•  Task  has  a  bingo  time 

•  Task  is  the  final  airlock  ingress 

Table  1  is  the  input  template  for  the  data  described  above. 


Priority 

DurEVl 

DurEV2 

Mandatory 

E 

CD 

■a 

c 

CD 

(- 

Airlock 

u 

X 

o 

1- 

FlasWindow 

o 

DO 

c 

bo 

</i 

CD 

X 

BingoTime 

PVGF_Release_from_EP 

5 

5 

6 

0 

0 

0 

0 

0 

0 

0 

Pl_Worksite_Setup 

5 

30 

33 

0 

0 

0 

0 

0 

0 

0 

Remove_CLA 

5 

10 

11 

0 

0 

0 

0 

0 

0 

0 

Translate_Failed_LEE_to_ELCl 

5 

30 

30 

0 

1 

0 

0 

0 

0 

0 

Spare_LEE_Prep 

5 

45 

50 

0 

0 

0 

0 

0 

0 

0 

Stow_Fa  i  1  e  d_LEE_on_T  e  m  p_Stow_Ri  ng 

5 

35 

35 

0 

1 

0 

0 

0 

0 

0 

Retireve_SpareJ.ee 

5 

40 

40 

0 

1 

0 

0 

0 

0 

0 

Translate_Spare_LEE_to_Pl_Worksite 

5 

30 

30 

0 

1 

0 

0 

0 

0 

0 

Install  JILA 

5 

10 

11 

0 

0 

0 

0 

0 

0 

0 

1  nstal  l_LEE 

5 

30 

30 

0 

1 

0 

0 

0 

1 

270 

LEE_FSE_Cleanup 

5 

9 

10 

0 

0 

0 

0 

0 

0 

0 

Remove_LEE 

5 

40 

40 

0 

1 

0 

0 

0 

0 

0 

Cleanupjngress 

5 

30 

30 

1 

1 

1 

0 

0 

0 

0 

Egress_Setup 

5 

15 

15 

1 

1 

0 

0 

1 

0 

0 

Table  1.  Task  input  data  template 


Tasks  that  have  time  windows  have  additional  data  input  requirements.  In 
addition  to  flagging  them  in  the  above-mentioned  template,  the  allowable  time  windows 
must  be  specified  separately.  For  each  such  task,  the  following  data  are  required 
(template  shown  in  Table  2). 

•  Window,  task  joint  identifier 

•  Start  time  of  each  window  (in  minutes,  PET) 

•  End  time  of  each  window  (in  minutes,  PET) 


tmin 

tmax 

wl 

Egress_Setup 

0 

30 

wl 

Sample_Task 

30 

65 

w2 

Sample_Task 

90 

100 

w3 

Sample_Task 

210 

220 

Table  2.  Task- time  window  input  data  template 
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2. 


Precedence  Relationships 


Tasks  with  precedence  relationships  are  specified  in  a  separate  input  file  via  a 
predecessor-successor  data  structure.  Tasks  can  be  paired  or  chained  with  any  number  of 
other  tasks  to  create  unique  and  complicated  relationships.  Table  3  shows  a  typical 
precedence  relationship  input  in  the  template. 


Predecessor 

Successor 

Pl_Worksite_Setup 

Remove_CLA 

Remove_LEE 

Translate_Failed_LEE_to_ELCl 

Remove_CLA 

Translate_Failed_LEE_to_ELCl 

Translate_Failed_LEE_to_ELCl 

Stow_Failed_LEE_on_Temp_Stow_Ring 

Spare_LEE_Prep 

Retrieve_Spare_Lee 

Translate_Failed_LEE_to_ELCl 

Retrieve_Spare_Lee 

Retrieve_Spare_Lee 

Translate_Spare_LEE_to_Pl_Worksite 

Remove_CLA 

1  nstal  l_CLA 

Remove_LEE 

1  nstal  l_CLA 

Translate_Spare_LEE_to_Pl_Worksite 

1  nstal  l_CLA 

1  nstal  l_C  LA 

1  nstal  l_LEE 

Translate_Spare_LEE_to_Pl_Worksite 

1  nstal  l_LEE 

Retrieve_Spare_Lee 

LEE_FSE_Cleanup 

Stow_Failed_LEE_on_Temp_Stow_Ring 

LEE_FSE_Cleanup 

Translate_Spare_LEE_to_Pl_Worksite 

LEE_FSE_Cleanup 

Remove_CLA 

Remove_LEE 

Pl_Worksite_Setup 

Remove_LEE 

PVGF_Release_from_EP 

Remove_LEE 

Stow_Failed_LEE_on_Temp_Stow_Ring 

Retrieve_Spare_Lee 

Table  3.  Task  precedence  relationship  input  data  template 


3.  Task  Location  Data 

All  tasks  have  associated  worksites.  Since  some  tasks  can  include  a  movement  of 
the  crewmember  from  one  worksite  to  another,  the  model  requires  inputs  for  both  the 
starting  and  ending  location  of  each  task  (see  Table  4).  For  convenience  in  our 
implementation,  these  two  locations  are  entered  in  separate  files. 
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Task 

Initial  Location 

Final  Location 

PVGF_Release_from_EP 

HTV 

HTV 

Pl_Worksite_Setup 

Columbus_WIF3 

Pl_Worksite 

Remove_CLA 

Pl_Worksite 

Pl_Worksite 

Translate_Failed_LEE_to_ELCl 

Pl_Worksite 

ELC1 

Spare_LEE_Prep 

ELC1 

ELC1 

Stow_Failed_LEE_on_Temp_Stow_Ring 

ELC1 

ELC1 

Retrieve_Spare_l.ee 

ELC1 

ELC1 

Translate_Spare_LEE_to_Pl_Worksite 

ELC1 

Pl_Worksite 

1  nstal  l_CLA 

Pl_Worksite 

Pl_Worksite 

1  nstal  ILEE 

Pl_Worksite 

Pl_Worksite 

LEE_FSE_Cleanup 

ELC1 

ELC1 

Remove_LEE 

Pl_Worksite 

Pl_Worksite 

Cleanupjngress 

Airlock 

Airlock 

Egress_Setup 

Airlock 

Airlock 

Table  4.  Task  location  input  data  template 


4.  Translation  Times 

In  order  to  convert  the  task  location  information  into  data  useful  for  the  EPM,  the 
translation  time  between  all  worksite  locations  associated  with  a  given  set  of  tasks  must 
be  provided.  The  values  are  given  in  minutes  and  entered  in  a  matrix  format  as  seen  in 
Table  5.  Note  that  the  matrix  allows  for  different  translation  times  depending  on  the 
direction  traversed. 


To 

From 

Airlock 

HTV 

ELC1 

Pl_Wrkst 

Col_WIF3 

Airlock 

0 

10 

15 

13 

8 

HTV 

10 

0 

20 

13 

2 

ELC1 

15 

20 

0 

13 

20 

Pl_Wrkst 

13 

13 

13 

0 

13 

Col_WIF3 

8 

2 

20 

13 

0 

Table  5.  Translation  time  input  data  matrix 
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5. 


Model  Constants 


The  model  utilizes  several  constants  which  can  be  adjusted  if  needed  to  change 
the  parameters  of  certain  planning  constraints  or  to  weight  the  relative  prioritization  of 
model  objectives.  These  constants  and  their  default  values  are: 

•  Priority  Rank  Weight  [unitless],  default  value  =  0.1 

•  Rank  Start  Time  Weight  [value/min],  default  value  =  0.0001 

•  Total  EVA  length  [minutes],  default  value  =  390  minutes 

•  Latest  bake-out  start  time  [minutes],  default  value  =  240  minutes 
E.  FORMULATION 

This  section  introduces  the  mathematical  formulation  of  the  EPM  as  a  linear 
mixed-integer  program  (MIP)  that  can  be  used  to  create  or  modify  EVA  summary 
timelines. 

I,  Mathematical  Model 

Sets: 

J ,  set  of  tasks,  where  j  is  the  airlock  ingress  task 

K ,  set  of  ranks  (task  sequencing  order),  where  K  =  |l,2,...|A|| 

C ,  set  of  crew  members,  where  C  =  {EV1,  EV2] 

T  ,  subset  of  J  that  requires  two  crew  members.  Note:  j  e  T 

Q ,  subset  of  pairs  of  tasks,  (j,j')eQczJxJ,  where  j  precedes  j ' 

M ,  subset  of  J  comprised  of  mandatory  tasks  that  must  be  completed 

regardless  of  priority.  Note:  j  e  M 

H  ,  subset  of  J  which  carry  the  risk  of  toxic  fluid  contamination  on 

EMU  suit 

L  ,  subset  of  J  which  must  be  scheduled  in  time  constrained  windows, 

defined  in  set  W 
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W ,  set  of  time  windows  defining  allowable  periods  to  perfonn  tasks 

identified  in  set  L 

J° ,  subset  of  L  which  cannot  start  at  time  zero  (i.e.,  do  not  have  a  time 

window  that  includes  time  0). 

B  ,  subset  of  J  which  has  a  bingo  time  constraint  (i.e.,  task  must  be 

scheduled  such  that  it  will  be  completed  by  a  certain  time  or  it 
should  not  be  attempted) 

Data  [units]: 

dj  c ,  duration  of  task  j  for  crewmember  c  (for  tandem  tasks  it  should 

be  made  the  same  for  both  crew  irrespective  of  their  skills)  [min] 

Pj ,  priority  value  of  task  j  [value] 

cop ,  objective  function  weighting  coefficient  for  task  priority  [unitless] 

of  ,  objective  function  weighting  coefficient  for  task  start  time 

[value/min] 

Xj  ., ,  translation  time  between  tasks  j  and  j '  (based  on  the  final  and 

initial  locations  for  both  tasks,  respectively)  [min] 

A  ,  latest  airlock  ingress  completion  time  (this  is  the  maximum 

allowable  EVA  duration)  [min] 

8  ,  latest  bake-out  start  time  [min] 

P j ,  latest  start  time  for  task  j  e  B  [min] 

t"™  ,  first  allowable  start  time  in  window  w  for  task  /  e  L  [min] 

t™x ,  latest  allowable  end  time  in  window  w  for  task  /  e  L  [min] 

Decision  Variables  [units]: 

Y j  kc,  1  if  task  j  is  selected  in  rank  k  for  crewmember  c ,  0  otherwise 
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start  time  for  rank  k  of  crewmember  c  [min] 


Sk,c  5 

Uj  c ,  start  time  for  task  j  for  crewmember  c  [min] 

Vjj,kc,  1  if  task  /'  follows  task  j  in  adjacent  ranks,  k  and  k  + 1  for 

crewmember  c ,  0  otherwise 

Rw  .  ,  1  if  task  j  is  scheduled  in  window  w  for  crewmember  c ,  0 

otherwise 

Objective  Function: 


maximize 


I 


jej  ,ke.K  ,ceC 


1  + 


co H 


y,*,-  I 


a) 


keK.ceC 


Subject  To: 

7y  4  ce{ 0,1},  V/  <e  J,k  sK,c  sC 
Rwj,c  e  {°>  1} ,  Vw  e  W,  j  e  J,  c  e  C 

e { 1 o»  1} ,  vy, y &j,k^K,c^c 


Skc>0,  VkeK,ceC 
U j  c  >  0,  V/eJ,ceC 


(2) 


(3) 


c/,.c>^c-2A(i-y.,!C), 

C/7.c<^c+2zl(l-7.^), 

Uj^^YJXc, 

keK 


\/j  e  J ,k  e  K,c  e  C 
V/  eJ,k  e  K,c  eC 
V j  eJ,c  eC 


(4) 


ViEA-.CEC 

j&J  j^J 


(5) 
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(6) 


U,  +d,<A,  VcgC 

J,c  J  ’ 


U.  <U,  , 

J,c  J,C ’ 


\/j  eJ,c  eC 


(7) 


Z  ^£1. 

k&K,ceC 

Z  7"y,t,c - 7  t  y/er\M 

keK,c&C 


(8) 


Z^,,=Z^.v/^  w 


^,1=^,2 


V/'eT 


(10) 


X  rMie=i,  VjeM\r 

keK,c&C 

Z  ^...=2.  V/eMnr 

keK,ceC 


(ID 


E7M,c-1’  VkcK,ceC  (12) 


<Ve  -  ^.c  +  ^jdj,cYj,k,c  +  X 


j,j\k,c 


jcJ  j,j'*J\j*j' 

V  <Y 

f  j,j',k,c  -  ±j,k,c  ’ 

F  <7 

j,j',k,c  ~~  j',k+l,c  9 

7  >7  +7  _i 

v  j,j\k,c  —  1j,k,c  ^  1  j\k+\,c  1  ’ 


\/k  e  K,c  e  C 

\/j,j'eJ,keK,ceC\j*j'  ^ 
Y/J'e  J,keK,ceC\j*j' 
\/j,j'eJ,keK,ceC\j*j' 


43 


Z  W  X  K 


j,k,c  ? 


keK,ceC 


keK,ceC 


1  V  y  <  V  Y 

O  '  i  ±  j\k,c  ~  /  j  ±  j,k,c  "> 


'  keK,ceC 


keK,ceC 


X  rrt^\  X 


Y 


j,k,c  ’ 


VjJ'eQ\jJ'eTvj,j'eT 

VjJ'eQ\j*T,j'eT 

VjJ'eQ\jeT,j'tT 


keK,ceC 


keK,ceC 


Xur^X(uu+duXY,M>-2^ ■-  £  W  *i’j'eQ\J’J'*T 

ceC  ceC  keK  keK,ceC 

kB'rMXP»*a»X?i**>-2w-  X  w-  w«cu,r«r 


ceC 


ceC 


keK 


keK,ceC 


\xu r,^X(u :,*duXYit.c)-^('1-  X  W>  vy,/«eiy«r,/.r 


ceC 


ceC 


keK 


keK,ceC 


XFr^\X^uj,cYdj,XYi*J-2Ml-  I  Yr,k,c)’  Vf,fQ\j*T,f*T 

ceC  ^  ceC  keK  keK,ceC 


(14) 


U jc  <8-  djc  ,  \/j  e  H ,c  e  C 


(15) 


Ujc<pj-djc  ,  V/  c.  /Ac  c  C 


(16) 


V  tminf?  .  <  t/.  <  y  (tmax  -  J  k  .  ,  V;  e  L,c  e  C 

xv, j  w,j ,c  j ,c  y  w,y  J /  w,y,c  ^  J  ^ 

xveW  weW 

XK,,^XY,*„’  VjeL.ceC 


(17) 


weW  keK 


y.(  <V:C  .  V/  e  J°  ,k  e  K,c  eC  (18) 

2.  Model  Description 

Equation  (1)  is  the  objective  function  of  the  EPM.  The  objective  is  to  maximize 
the  total  priority  value  of  tasks  selected,  and  to  maximize  the  priority  per  unit  time 
throughout  the  EVA.  Indirectly,  by  pushing  tasks  earlier  when  possible,  the  latter  should 
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minimize  early  idle  time  during  the  EVA  (excluding  the  idle  time  for  an  EV  waiting  for 
the  other  crewmember  before  airlock  ingress).  The  objective  Unction  is  broken  into  two 
distinct  terms  to  accomplish  these  goals. 

Examination  of  the  first  term  reveals  that  it  is  a  variation  of  the  knapsack 
objective  formulation  combined  with  the  HPF  and  PR  concepts  derived  from  the  job  shop 
problem  as  discussed  in  Section  II.A.4.  Tasks  are  selected,  assigned  to  a  crewmember, 
and  placed  into  a  series  of  sequential  ranks,  k  e  {1,2,3,...|A|}  .  Each  of  the  selected  task's 

priority  values  contribute  to  the  total  objective  value,  but  those  values  are  decreased  by  a 
factor  that  is  inversely  proportional  to  their  assigned  rank  number.  This  results  in  a 
penalty  for  placing  tasks  of  equal  priority  into  later  ranks.  It  can  be  easily  proven  that,  all 
else  being  equal,  a  task  with  higher  priority  value  will  be  preferred  for  a  lower  rank  after 
adjusting  priorities  with  the  (l  +  ®%)  factor. 

The  second  term  in  the  objective  function  serves  the  purpose  of  imposing  a 
penalty  on  unnecessary  gaps  between  rank  start  times  (and  thus  between  task 
assignments).  This  has  three  effects:  (1)  to  push  tasks  as  early  as  possible  in  the  EVA 
(helping  to  minimize  idle  time),  (2)  to  minimize  the  duration  of  an  EVA  that  has  fewer 
than  the  maximum  number  of  tasks,  and  (3)  to  enforce  a  job  shop  style  line  balancing 
between  the  two  crew  members. 

The  two  constants,  cop  and  of  ,  are  values  which  establish  the  relative  importance 
of  the  task  selection  by  priority  and  early  scheduling,  respectively. 

The  constraint  equations  that  follow  are  organized  into  multiple  groups,  each  with 
a  single  associated  equation  number.  In  cases  where  the  group  as  a  whole  is  referenced, 
we  use  the  given  equation  number  for  the  group  (x),  whereas  the  y-th  explicit  expression 
within  that  group  will  be  referenced  in  the  fonnat  (x.y). 

Equation  (2)  defines  the  three  types  of  binary  decision  variables  and  Equation  (3) 
defines  the  rank  and  task  start  time  variables  as  being  non-negative.  Equation  (4) 
establishes  the  relationship  between  rank  start  times  and  task  start  times.  The  start  time 
for  any  task  is  set  equal  to  the  start  time  of  the  rank  for  which  it  is  slotted.  If  the  task  is 
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not  scheduled,  the  associated  start  time  is  unconstrained.  The  constant  2  A  is  used  as  it 
represents  an  upper  bound  to  all  allowable  values  of  Ujc.  Additionally,  all  task  start 

times  are  constrained  to  occur  before  latest  airlock  ingress  time.  Equation  (5)  stipulates 
that  no  empty  ranks  can  exist  prior  to  a  rank  which  is  assigned  a  task.  This  is  required  to 
ensure  that  translation  times  are  properly  accounted  for  later  (in  particular,  in  Equation 
(13)).  Equation  (6)  forces  the  airlock  ingress  task  (identified  as  j),  which  is  always  the 
final  task  of  an  EVA,  to  be  completed  no  later  than  a  pre-specified  maximum  EVA 
duration  of  A ,  while  Equation  (7)  ensures  that  the  airlock  ingress  is  the  final  scheduled 
task  by  eliminating  any  task  start  times  after  it. 

Equation  (8)  prevents  the  repeated  selection  of  tasks  for  both  solo  and  tandem 
tasks.  Equations  (9)  and  (10)  provide  tandem  task  constraints  such  that  a  tandem  task 
must  be  scheduled  for  both  crewmembers  or  not  at  all,  and  that,  if  scheduled,  start  time  of 
tandem  tasks  must  be  the  same  for  both  crewmembers.  Mandatory  task  assignment  is 
handled  by  Equation  (11),  forcing  all  tasks  flagged  as  mandatory  to  be  selected.  It 
includes  a  coverage  of  solo  and  tandem  mandatory  tasks.  Equation  (12)  prevents  any 
conflicts  associated  with  oversubscribing  ranks.  Each  crewmember  can  have  no  more 
than  one  task  assigned  to  each  rank. 

The  group  of  constraints  given  in  Equation  (13)  are  related  to  crew  movement 
between  tasks.  Translation  time  between  task  worksites  is  accounted  for  by  exploiting  the 
fact  that  Equation  (5)  disallows  skipped  ranks.  Thus  we  know  that  tasks  slotted  into  ranks 
k  and  k  + 1  for  a  given  crewmember  must  be  adjacent  in  time.  The  index  /'  is 
introduced  to  allow  us  to  represent  two  independent  tasks  from  set  J  in  the  same 
equation.  Binary  variable  Vj  yk  c  is  introduced  to  allow  a  linear  expression  indicating  that 

a  transition  between  two  specific  tasks,  j  and  j '  occurs.  Equations  (13.2)  -  (13.4)  ensure 
that  V,  k  c  takes  a  value  of  one  if  and  only  if  task  j  is  scheduled  in  rank  k  and  task  j ' 

is  scheduled  in  rank  k  + 1  for  crew  member  c .  Once  the  translation  order  is  established, 
Equation  (13.1)  constrains  the  start  time  of  the  next  rank  to  include  the  previous  rank's 
task  duration  and  the  appropriate  translation  time,  x .  ., . 
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Equation  block  (14)  handles  task  precedence  for  the  general  case  and  several 
special  cases.  Firstly,  Equations  (14.1)  through  (14.3)  ensure  that  a  successor  task, 
indicated  by  / ',  cannot  be  selected  if  the  predecessor  task  has  not  been  selected.  The 
remaining  equations  constrain  the  start  time  of  successor  tasks  to  be  after  the  completion 
time  of  any  predecessors.  If  j  is  never  completed,  then  U rc  is  unconstrained,  thus  /' 

will  never  be  scheduled  if  j  is  not  scheduled,  but  j  may  be  scheduled  even  if  j '  is  not. 
The  multiple  versions  of  these  expressions  in  Equation  block  (14)  are  required  to  handle 
all  permutations  of  tandem  and  solo  tasks  among  tasks  with  precedence  relationships. 

Equation  (15)  handles  tasks  flagged  as  having  a  possibility  of  EMU 
contamination  with  toxic  materials  and  forces  them  to  be  completed  prior  to  the  latest 
bake-out  time,  8  .  Note  that  bake-out  requires  a  period  of  sun  exposure  for  the  EMU  suit 
and  is  therefore  dependent  on  sunrise  and  sunset  times.  Since  there  is  a  sunrise  and  sunset 
every  45  minutes  at  the  orbital  velocity  of  the  ISS  and  many  factors  (including  some 
unplanned  factors)  contribute  to  a  variability  of  the  crew's  workday  in  relation  to  orbital 
day  and  night,  the  phasing  between  sunlight  conditions  and  PET  cannot  usually  be  known 
until  relatively  close  to  the  time  of  EVA  execution.  Fully  optimizing  the  bake-out 
constraint  through  the  setting  of  8  is  difficult  during  the  planning  phase,  which  can 
occur  months  prior  to  the  actual  EVA.  A  conservative  approach  to  establishing  the  bake- 
out  start  time  would  be  to  simply  set  8  at  a  level  that  guarantees  a  sufficient  bake-out 
regardless  of  orbital  sunrise  and  sunset  times.  This  worst  case  would  prompt  the  user  to 
set  8  =  A- d~.  -d.-x.--A5,  that  is  the  EVA  end  time  minus  the  combined  duration 

y.c  °’c  j,j  ’ 

of  airlock  ingress,  the  bake-out  activity,  the  translation  time  between  the  hazardous  task 
and  the  airlock,  and  a  45  minute  pad  for  worst-case  day/night  phasing. 

Equation  (16)  constrains  the  start  time  of  tasks  which  have  been  flagged  as  having 
a  bingo  time.  These  are  tasks  which  must  be  completely  finished  to  avoid  an  undesirable 
configuration  of  the  vehicle  or  have  some  other  negative  consequence  if  left  incomplete. 
Each  task  in  set  B  can  have  its  own  unique  bingo  time,  so  they  are  handled  individually. 

Equations  (17)  and  (18)  handle  constraints  for  tasks  with  specific  allowable  task 
windows.  Task  windows  are  defined  by  the  user  with  a  beginning  time  and  end  time.  For 
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a  task  flagged  as  having  a  time  window,  there  is  no  limit  to  the  number  of  allowable 
windows  it  can  have.  The  model  requires  that  the  entire  duration  of  the  task  fits  into 
whichever  window  is  selected.  We  introduce  the  binary  decision  variable,  Rwjc,  to 

denote  selection  of  a  specific  window  for  a  given  task.  Equation  (17.1)  constrains  the 
start  time  of  the  task  to  be  such  that  the  entire  task  will  fit  in  the  defined  window,  while 
Equation  (17.2)  ensures  that  a  window  is  selected  if  and  only  if  the  associated  task  has 
been  selected.  Equation  (18)  handles  the  special  case  of  tasks  with  time  windows  that  do 
not  include  PET  =  0  minutes.  Specifically,  it  disallows  the  start  time  of  the  task  to  be  0 
minutes  if  the  task  is  selected. 

3.  Implementation 

The  EPM  is  implemented  in  the  General  Algebraic  Modeling  System  (GAMS) 
(Brooke  et  ah,  2012)  and  all  EPM  runs  described  in  this  research  are  solved  using 
CPLEX  (GAMS/CPLEX,  2012)  as  a  solving  engine,  on  a  desktop  computer  equipped 
with  an  Intel  Core  i7  CPU  with  eight  processor  cores  running  at  2.67  GHz  and  6  GB  of 
RAM. 

A  typical  instance  of  EPM,  such  as  black-box  test  case  Id,  described  in  detail  in 
Chapter  IV,  has  approximately  19,000  constraints  and  6,800  binary  variables.  Solve  time 
for  an  optimal  solution  (at  0%  optimality  gap)  ranges  between  2  minutes  and  18  hours. 
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III.  MODEL  TESTING  AND  VERIFICATION 


This  chapter  describes  the  testing  approach  used  to  verify  the  EPM  and  presents 
model  results.  We  employ  verification  techniques  to  provide  thorough  vetting  of  the 
model's  correctness.  Note  that  while  verification  is  crucial  for  the  EPM,  full  validation  is 
not  addressed  here.  This  stems  from  the  fact  that  the  EPM  has  been  built  specifically  to 
address  the  requirements  in  Chapter  II,  where  any  planning  requirements  that  are  deemed 
too  complicated  for  the  initial  development  of  the  model  have  been  relaxed  or  omitted. 
Accordingly  the  model  testing  presented  in  this  work  seeks  to  demonstrate  EPM  at  the 
proof-of-concept  level,  striking  a  balance  between  actual  problem  requirements  and 
capabilities  for  practical  use  in  EVA  plan  development. 

A.  METHODOLOGY 

A  full  quantitative  evaluation  of  the  quality  of  the  EPM  in  the  traditional  sense  is 
not  possible  at  this  time.  This  is  a  result  of  several  factors:  (1)  there  is  no  established 
metric  available  to  compare  the  quality  of  one  EVA  plan  to  another,  (2)  EVA  planning 
relies  heavily  on  heuristic  approaches,  and  (3)  decisions  made  in  finalized  EVA  plans  are 
not  typically  documented  in  a  form  that  allows  us  to  know  which  alternatives  were 
considered  and  why  they  were  rejected. 

The  manual  nature  of  EVA  planning  is  the  biggest  barrier  to  the  creation  of  an 
autonomous  EVA  planning  tool.  It  is  also  the  most  problematic  aspect  of  approaching  the 
question  of  measuring  the  output  quality  of  even  our  basic  EPM.  Of  course,  many  of  the 
decisions  involved  in  planning  an  EVA  relate  to  which  tasks  will  be  included  and  the 
order  in  which  they  will  be  scheduled,  but  many  more  are  related  to  the  sub-division  of 
tasks.  Tasks  may  be  sub-divided  for  myriad  reasons,  including,  but  not  limited  to: 
optimization  of  task  locations  to  best  utilize  tether  points,  handholds,  and  permanent  or 
moveable  work  fixtures,  the  tools  required,  and  the  body  positioning  or  approach  path  for 
the  crew.  These  complexities  have  been  omitted  from  the  EPM  in  order  to  simplify  it 


49 


enough  to  make  its  development  practical  within  this  study.  While  this  simplification  is 
necessary  to  limit  the  scope  of  model  development  to  a  feasible  size,  it  also  rules  out  a 
strictly  quantitative  testing  standard. 

Given  the  lack  of  an  ultimate  quality  metric,  we  focus  our  testing  strategy  on 
verifying  that  the  implemented  features  execute  as  expected.  The  question  of  verification 
is  by  no  means  a  simple  one  because  the  optimization  model  includes  many  nested 
logical  conditions  to  account  for  constraints.  Very  few  of  these  constraints  are  mutually 
exclusive,  making  testing  a  significant  challenge.  To  develop  a  credible  verification 
testing  plan  that  remains  manageable,  we  look  to  the  field  of  software  engineering.  In  this 
way,  we  view  the  EPM  M1P  formulation  as  a  series  of  logical  “if-then”  statements  as  in  a 
standard  computer  program.  Each  constraint  (or  group  of  constraints  with  a  particular 
joint  function)  becomes  a  branch  in  the  logic  tree  of  the  program  that  (when  combined 
with  all  the  others)  comprises  the  EPM. 

One  potential  approach  to  test  such  a  program  is  exhaustive  testing,  wherein  we 
test  every  possible  logical  combination  in  the  model  to  ensure,  ostensibly,  that  no  errors 
remain  undetected.  Even  in  a  very  simple  program  with  a  small  number  of  if-then 
constructs,  exhaustive  testing  is  an  exceedingly  daunting  proposition  and  that  for  large  or 
complex  software  systems  it  is  effectively  impossible.  Exhaustive  testing  is  a  form  of 
"white-box"  testing  which  "is  predicated  on  close  examination  of  procedural  detail. 
Logical  paths  through  the  software  and  collaborations  between  components  are  tested  by 
exercising  specific  sets  of  conditions"  (Pressman,  2010,  p.  484).  White-box  testing 
provides  exactly  what  we  need  to  verify  a  model  like  the  EPM  and  thus  forms  an 
important  part  of  our  testing  strategy. 

Our  methodology  is  based  on  these  guidelines  suggested  by  Davis  (1995):  (1) 
tests  should  be  planned  before  testing  begins,  (2)  testing  should  start  "in  the  small"  and 
progress  toward  "in  the  large,"  (3)  the  Pareto  principle  applies  to  software  testing  (80%  of 
errors  will  likely  be  traced  to  20%  of  the  program  components),  and  (4)  exhaustive 
testing  is  not  possible  (as  cited  in  Pressman,  2010).  EPM  testing  is  accomplished  in  three 
phases  which  progress  in  scope  from  single  elements  to  the  entire  model.  We  begin  with 

unit  testing  of  the  individual  components,  move  on  to  white-box  testing  of  logical 
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sequences  or  processes,  then  to  “black-box”  testing.  Black-box  testing  is  not  concerned 
with  the  internal  workings  of  a  software  element,  but  rather  focuses  on  its  ability  to 
produce  expected  outputs  from  known  inputs.  Black-box  testing  will  provide  the  ultimate 
measure  of  the  acceptability  of  the  model  as  a  whole  and  provide  insight  as  to  the 
feasibility  of  further  development  of  the  EPM  into  an  operational  tool. 

B.  UNIT  TESTING 

Throughout  the  development  of  the  EPM,  unit  testing  was  constantly  perfonned 
to  verify  functionality  of  individual  components.  The  purpose  of  unit  testing  is  to 
examine  the  basic  building  blocks  of  the  model.  The  goal  is  to  create  test  cases  that 
exercise  the  smallest  components  while  also  reducing  interaction  with  other  segments  as 
much  as  possible.  See  Tables  6  and  7  for  documentation  of  the  unit  tests  and  their  results. 
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Unit  Test 

Number 

Test  Configuration 

Expected  Output 

Test  Result 

Test  Goal 

Test  Setup 

0 

Verify  solo  tasks  can  be 
scheduled 

Input  set  of  solo  tasks  with 
no  special  constraints.  Total 
task  time  <  available  PET.  All 
translation  times  equal. 

All  tasks  scheduled 

Pass 

1 

Verify  no  uneccesary  idle 
time  in  output 

Same  as  case  0 

No  idle  time  is  included  between  any 
tasks 

Pass 

2 

Verify  translation  times  are 
accounted  for 

Same  as  case  0.  Translation 

times  between  all  locations 

are  unique. 

Translation  times  are  correct  and 

accounted  for 

Pass 

3 

Verify  crew  member 
assigment  is  optimized  (a) 

Same  as  case  0 

Task  assignment  is  split  between  crew 
members  such  that  they  have  relatively 
equal  total  task+translation  durations 

Pass 

4 

Verify  crew  member 
assigment  is  optimized  (b) 

Same  as  case  Obut  with  all 
tasks  having  equal  priority. 

All  tasks  have  a  duration  of 

10  minutes  if  assigned  to 

EV1,  half  of  the  tasks  have  a 

duration  of  30  minutes  if 

assigned  to  EV2. 

All  tasks  with  duration  difference 

assigned  to  EV1 

Pass 

5 

Verify  crew  member 
assigment  is  optimized  (c) 

Same  as  case  4  but  with  all 
tasks  having  a  duration  of  10 
minutes  for  EV1  and  30 

minutes  for  EV2. 

Task  assignment  is  split  between  crew 
members  such  that  they  have  relatively 
equal  total  task+translation  durations 

Pass 

6 

Verify  tandem  tasks  can  be 
scheduled 

Same  as  case  0  but  with  at 

least  1  tandem  task(s)  in 
input  set. 

All  tandem  tasks  scheduled  for  both 

crew  members  at  the  same  PET 

Pass 

Table  6.  Unit  test  configurations  and  results  (unit  test  numbers  0-6) 
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Unit  Test 

Number 

Test  Configuration 

Expected  Output 

Test  Result 

Test  Goal 

Test  Setup 

7 

Verify  EVA  PET  is  limited  to 
specified  duration 

Input  set  of  solo  tasks  of 
equal  duration,  unique 
priority,  and  no  special 

constraints.  Total  task  time  > 

EVA  duration  is  limited  to  no  more  than 
the  specified  limit 

Pass 

8 

Verify  highest  priority  tasks 
selected 

Same  as  case  7. 

Tasks  included  in  EVA  to  fill  all  available 

PET,  excess  tasks  omitted  based  on 
priority  (lowest  are  omitted) 

Pass 

9 

Verify  mandatory  tasks  are 
selected 

Same  as  case  7  but  with  the 
lowest  priority  task  flagged 
as  mandatory. 

Mandatory  task  scheduled  at  the 
expense  of  a  higher  priority  task 

Pass 

10 

Verify  bingo  times  are 

adhered  to 

Same  as  case  9  but  with  the 

mandatory  task  assigned  a 
bingo  time. 

Mandatory  task  is  scheduled  such  that 
completion  is  prior  to  the  bingo  time 

Pass 

11 

Verify  bake-out  times  are 

adhered  to 

Same  as  case  9  but  with  the 
mandatory  task  flagged  as 

toxic. 

Mandatory  task  is  scheduled  such  that 
completion  is  prior  to  the  bake-out  time 

Pass 

12 

Verify  time  windows  are 

adhered  to 

Same  as  case  9  but  with  the 
mandatory  task  given  a 
specific  time  window. 

Mandatory  task  is  scheduled  such  that 
completion  is  within  the  specified  time 

window 

Pass 

13 

Basic  task  predence  is 

adhered  to 

Same  as  case  0  but  one  task 

is  assigned  a  predecessor. 

Successor  task  is  scheduled  after 

associated  predecessor  is  complete 

Pass 

14 

Verify  in-task  translations 
are  accounted  for 

Same  as  case  2  but  for  test 
task,  assign  different  initial 
and  final  locations. 

Translation  times  for  test  task  properly 
account  for  different  starting  and  final 

location 

Pass 

Table  7.  Unit  test  configurations  and  results  (unit  test  numbers  7-14) 


C.  WHITE-BOX  TESTING 

As  pointed  out  in  the  previous  sub-section,  ad  hoc  testing  became  an  important 
part  of  the  process  in  real-time.  As  new  capabilities  were  added  to  the  model,  simple 
impromptu  tests  were  performed  to  ensure  the  model  performed  acceptably.  Although 
these  tests  were  not  formally  organized  or  documented,  they  provided  valuable  insight 
about  where  errors  may  reside  in  the  logic.  Based  on  this  experience,  we  are  able  to 
empirically  confirm  the  application  of  the  Pareto  principle,  specifically  related  to  portions 
of  the  model  related  to  precedence  relationships.  We  also  found  that  errors  tended  to  lurk 
where  constraints  intersected,  for  example  precedence  relationships  between  solo  and 
tandem  tasks. 
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Exhaustive  testing  of  even  this  part  of  the  model,  as  pointed  out,  is  nearly  if  not 
wholly  impossible.  The  number  of  test  cases  needed  to  evaluate  all  possible  combinations 
of  constraints  is  astronomical.  In  fact,  the  number  of  test  cases  is  unbounded  since  there 
is  no  limit  to  the  number  of  tasks  (and  associated  attributes)  that  can  be  fed  into  the 
model.  As  such,  we  utilize  the  concept  of  basis  path  testing  for  the  EPM.  Basis  path 
testing  is  a  form  of  limited  white-box  testing  commonly  used  for  software  programs  with 
large  logical  control  structures.  To  perfonn  this  type  of  testing,  we  first  conceptualize  the 
EPM  as  a  series  subroutines  comprised  of  if-then  statements.  We  then  create  control  flow 
graphs  for  the  subroutines  and  determine  all  possible  logical  paths  through  the  graphs. 
These  paths  are  referred  to  as  a  basis  set  and  by  creating  test  cases  for  each  basis  set,  we 
ensure  that  each  logical  path  within  the  subroutine  will  be  exercised  at  least  once  with  the 
minimum  number  of  test  cases  (Pressman,  2010).  While  it  is  certainly  possible  for  errors 
to  slip  though  this  testing,  the  technique  provides  a  very  attractive  return  on  investment  in 
terms  of  testing  efficiency.  The  number  of  test  cases  required  to  complete  basis  path 
testing  is  given  by  the  cyclomatic  complexity  of  the  subroutine's  control  flow  graph. 
Calculating  the  cyclomatic  complexity,  V (G) ,  from  the  graph  can  be  accomplished  by 
simply  counting  the  regions  bounded  by  the  edges  and  nodes  in  the  graph  (plus  the  region 
outside  the  graph)  or  by  using  one  of  the  calculations  below: 

V(G)  =  E-N  +  2 
V(G)  =  P  + 1 

In  the  first  expression,  E  is  the  number  of  edges  and  N  is  the  number  of  nodes 
in  the  flow  graph.  In  the  second  expression,  P  is  the  number  of  predicate  nodes.  A 
predicate  node  is  a  node  which  contains  a  decision  and  thus  has  more  than  one  edge 
exiting  from  it. 

Figure  8  shows  the  control  flow  graph  for  the  precedence  relationship  portion  of 
the  EVM.  All  three  methods  above  yield  V(G)  =  13  and  thus  the  basis  set  contains  13 
independent  paths.  This  defines  the  number  of  test  cases  that  must  be  run  to  test  every 
part  of  the  subroutine  at  least  once.  The  flow  graph  is  built  from  the  perspective  of  a 
specific  task,  j ,  which  is  considered  by  the  model  for  placement  in  a  timeline.  It  shows 
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the  multiple  factors  that  play  into  scheduling  a  task  with  predecessors,  including  whether 
feasible  start  times  (notated  by  the  shorthand  "  U  "  in  the  graph)  exist.  This  routine  is  used 
to  establish  if  task  j  can  be  scheduled  and  to  define  when  it  can  be  scheduled.  Assuming 
the  task  can  be  scheduled,  there  is  no  guarantee  that  it  will  be  scheduled,  the  routine 
simply  allows  the  rest  of  the  optimization  model  to  consider  the  task  alongside  all  other 
candidates,  while  observing  the  timing  limitations  placed  upon  it  by  its  precedence 
relationships. 

One  notable  exception  from  the  flow  graph  is  a  check  if  task  j  is  flagged  as 
mandatory.  This  is  omitted  because  the  model  will  exit  without  a  solution  in  the  case  of  a 
mandatory  task  that  is  impossible  to  schedule  for  any  reason.  Since  we  know  such  an 
input  configuration  will  cause  the  model  to  fail  to  complete,  there  is  no  need  to  include  it 
in  the  graph. 
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Figure  8.  EPM  precedence  relationship  control  flow  graph 
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Table  8  is  the  complete  listing  of  all  13  path  test  cases  comprising  the  basis  set 
generated  from  the  flow  graph  in  Figure  8,  their  configurations,  expected  outputs,  and 
results.  The  original  test  results  (not  shown)  proved  very  useful  as  several  errors  in  the 
model  formulation  and/or  code  were  identified  and  corrected  as  a  result  of  performing  the 


test  cases.  Table  8  displays  all  tests  passed  after  the  errors  were  corrected. 


Path  Test 

Number 

Test  Configuration 

Expected  Output 

Test  Result 

Characteristics  of 

Predecessor  Task,  j P 

Characteristics  of  Test  Task, 

ir 

0 

n/a 

Task  jT  has  no  predecessors 

Task  jT  scheduled 

Pass 

1 

Not  complete 

n/a 

Task  ;r  not  scheduled 

Pass 

2 

Completed,  Solo 

Solo,  no  window,  no  bingo, 

not  toxic 

Task  jT  scheduled  aftery> 

Pass 

3 

Two  predecessor  tasks,  both 
completed 

Solo,  no  window,  no  bingo, 

not  toxic 

Task  jT  scheduled  after  both 
predecessors 

Pass 

4 

Completed,  Tandem 

Solo,  no  window,  no  bingo, 

not  toxic 

Task/r  scheduled  after; P 

Pass 

5 

Completed,  Tandem 

Tandem,  no  window,  no 
bingo,  not  toxic 

Task;,-  scheduled  after; P 

Pass 

6 

Completed,  Solo 

Tandem,  no  window,  no 
bingo,  not  toxic 

Task;,  scheduled  after; P 

Pass 

7 

Completed,  Tandem 

Solo,  infeasible  window,  no 
bingo,  not  toxic 

Task ;r  not  scheduled 

Pass 

8 

Completed,  Tandem 

Solo,  feasible  window,  no 
bingo,  not  toxic 

Task JT  scheduled  after/p,  in  valid  time 

window 

Pass 

9 

Completed,  Solo 

Tandem,  no  window, 
infeasible  bingo  time,  not 

toxic 

Task ;r  not  scheduled 

Pass 

10 

Completed,  Solo 

Tandem,  no  window, 
feasible  bingo  time,  not  toxic 

Task/r  scheduled  after/p,  before  bingo 

time 

Pass 

11 

Completed,  Solo 

Tandem,  no  window, 
feasible  bingo  time, 
infeasible  bake-out  time 

Task  jT  not  scheduled 

Pass 

12 

Completed,  Solo 

Tandem,  no  window, 
feasible  bingo  time,  feasible 
bake-out  time 

Task/r  scheduled  after/p,  before  bake- 
out  and  bingo  times 

Pass 

Table  8.  EVM  precedence  relationship  basis  set  test  configurations  and  results 
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D.  BLACK-BOX  TESTING 

Black-box  testing  of  the  EPM  is  envisioned  as  a  large  scale  exercise  of  the  model 
as  a  complete  unit.  The  purpose  is  to  verify  that  the  model  can  successfully  create  an 
optimized  EVA  timeline  given  a  complete  set  of  input  data  (as  opposed  to  function- 
specific  testing).  The  results  of  this  testing  are  qualitative  and  by  no  means 
comprehensive,  but  this  testing  is  a  straightforward  approach  to  evaluating  overall  model 
capability.  Five  test  cases  are  generated  for  this  purpose.  Table  10,  found  at  the  end  of 
this  section,  compares  some  key  statistics  between  heuristic  and  EPM-generated 
timelines.  In  this  section,  "heuristic"  refers  to  a  solution  manually  generated  by  the  author 
(not  an  EVA  planner  expert)  using  reasonable  criteria  derived  from  interviewing  experts. 

1.  Black-box  Case  1  Configuration 

This  case  is  intended  to  show  optimization  of  task  selection  and  ordering  that  may 
be  time  consuming  or  counterintuitive  to  a  planner  using  manual  and/or  heuristic 
methods.  Figure  9  is  a  graphical  representation  of  this  case.  Each  circle  represents  a  task 
with  the  size  of  the  circles  representing  the  task's  relative  priority.  The  combined  duration 
of  the  input  tasks  is  greater  than  the  available  EVA  PET,  forcing  some  tasks  to  be 
excluded  from  the  plan.  As  shown,  tasks  are  split  into  three  worksites  with  arrows 
indicating  the  translation  times  between  worksites.  All  tasks  have  the  same  priority  value 
save  for  one  high-priority  (but  not  mandatory)  task.  Task  5  has  a  priority  value  that  is  1.5 
times  greater  than  each  of  the  other  tasks.  The  lower  priority  tasks  are  divided  into  two 
groups  of  co-located  tasks.  Worksites  for  both  of  these  groups  are  close  to  each  other  and 
to  the  airlock,  while  the  high-priority  task  is  located  far  from  all  of  them.  All  tasks  are 
tandem  and  of  the  same  duration.  The  green  circles  for  Task  1  and  Task  8  indicate  they 
are  mandatory,  as  these  are  the  airlock  egress  and  ingress  tasks,  respectively.  The  airlock 
egress  task  is  constrained  to  occur  first  by  the  use  of  a  time  window. 
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Worksite  B 


30  minutes 


Worksite  A 


Figure  9.  Black-box  test  case  1  configuration 


The  goals  of  this  test  case  are  to  determine  which  tasks  will  be  omitted  from  the 
timeline  and  how  the  model  will  sequence  the  tasks  given  the  large  time  penalty  for 
translating  to  and  from  worksite  A  to  complete  the  high-priority  Task  5.  We  will  also 
compare  the  model  result  to  a  basic  heuristic  approach  to  the  same  inputs  to  examine  the 
differences  between  the  two  results. 

2.  Black-box  Case  1  Results 

One  heuristic  approach  to  this  test  case  might  be  to  perform  the  highest  priority 
task  first,  then  move  to  worksite  B,  which  has  the  largest  concentration  of  tasks,  perform 
as  many  of  those  as  possible,  then  move  to  worksite  C  to  perform  tasks  there  if  time 
allows  before  returning  to  the  airlock.  That  approach  results  in  the  timeline  shown  at  the 
top  of  Figure  10  and  yields  an  objective  score  of  46.44  value  units. 

The  EPM  output  is  substantially  different.  Its  output  timeline  is  shown  at  the 
middle  of  Figure  10.  With  the  priority  ratio  of  3/2  between  Task  5  and  the  rest  of  the 
tasks,  the  model  determines  it  is  optimal  to  avoid  the  translation  penalty  to  worksite  A, 
and  instead  complete  a  greater  number  of  the  lower  priority  tasks  at  worksites  B  and  C. 
While  this  may  seem  counterintuitive,  the  objective  score  of  the  EPM  timeline  is  notably 
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better  at  52.52  value  units.  Table  10  shows  that  the  heuristic  timeline,  while  including  the 
highest  priority  task,  omits  twice  as  much  cumulative  task  priority  value  as  does  the  EPM 
solution. 

One  area  where  the  EPM  solution  is  clearly  inferior  to  the  heuristic  solution  is  in 
solve  time.  The  heuristic  solution  to  this  very  simplistic  case  is  fairly  intuitive  and  can  be 
created  very  rapidly  by  hand,  while  the  EPM  takes  nearly  1 1  hours  to  arrive  at  an  optimal 
solution.  There  are  many  possible  causes  for  this  poor  perfonnance,  one  of  which  may  be 
the  large  number  of  identical  tasks  included  in  this  test  case.  All  tasks  at  each  worksite 
are  exactly  the  same  in  all  respects.  As  a  result,  the  MIP  suffers  from  "symmetry,"  for 
instance,  the  EPM  solution  shows  Task  2  performed  first  and  Task  4  second,  but 
swapping  the  order  of  those  two  tasks  results  in  the  same  objective  score.  Another  factor 
is  the  relatively  close  priority  value  between  the  highest  priority  task  and  the  remaining 
tasks.  In  this  case  the  solution  is  clearly  much  less  obvious  than  the  heuristic  approach 
might  lead  one  to  believe. 

Finally,  we  note  that  in  authentic  summary  timelines,  translations  are  not  typically 
shown  as  separate  activities.  We  have  chosen  to  show  them  because  they  would  assist  an 
expert  in  assessing  the  efficiency  of  a  timeline  generated  by  the  model.  The  tasks  with  the 
format  "X  Y-Z"  in  the  summary  timelines  produced  by  the  EPM  are  translations  from 
location  "Y"  to  location  "Z." 
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3. 


Black-box  Case  la  Configuration 


To  see  the  effect  of  changing  the  priority  of  tasks,  we  increase  the  priority  of  Task 
5  to  triple  that  of  the  other  tasks,  leaving  all  other  parameters  the  same  as  in  Case  1 . 

4.  Black-box  Case  la  Results 

This  test  configuration  results  in  the  same  heuristic  solution  used  in  Case  1 .  The 
EPM  solution  (shown  at  the  bottom  of  Figure  10)  now  matches  the  heuristic  timeline 
exactly  (note  that  the  ordering  of  tasks  at  a  specific  worksite  is  interchangeable  since  all 
have  identical  properties).  The  EVA  proceeds  directly  to  worksite  A  to  perform  the  high 
priority  Task  5,  then  on  to  worksite  B  to  complete  all  tasks  there,  and  finally  to  worksite 
A  where  one  task  is  completed  before  returning  to  the  airlock.  This  problem  proves  much 
easier  for  the  EPM  to  reach  an  optimal  solution,  taking  only  22  minutes.  The  priority 
difference  in  this  situation  is  enough  to  make  Task  5  too  valuable  to  omit,  which  in  turn 
speeds  up  convergence  to  an  optimal  solution. 

5.  Black-box  Case  lb  Configuration 

To  see  the  effect  of  varying  the  duration  of  tasks,  we  modify  Case  1  by  making  all 
odd  numbered  tasks  (except  Task  1,  the  airlock  egress)  twice  the  duration  of  the  even 
numbered  tasks  (i.e.,  even  numbered  tasks  last  25  minutes,  odd  numbered  tasks  last  50 
minutes  in  this  case).  All  other  inputs  and  model  parameters  remain  the  same  as  those  in 
Case  1. 


6.  Black-box  Case  lb  Results 

The  heuristic  approach  for  this  case  consists  of  starting  at  the  nearest  worksite  (C) 
and  performing  the  shorter  tasks  first.  Since  it  is  clear  that  not  all  tasks  will  be  perfonned, 
the  only  50-minute  task  at  worksite  C  (Task  13)  is  also  performed  before  translating  to 
worksite  B.  Task  5  is  omitted  because  its  longer  duration  and  translation  penalty 
outweighs  its  higher  priority  value. 

The  EPM  solution  also  begins  at  worksite  C,  but  omits  Task  13  to  move  on  to 
worksite  B  and  perform  the  shorter  tasks  there  instead.  Both  timelines  accomplish  the 
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same  number  of  tasks,  but  the  EPM  scores  a  slightly  higher  objective  score  by  scheduling 
more  tasks  earlier  (the  model  timeline  completes  five  tasks  in  the  same  time  it  takes  the 
heuristic  to  perform  four).  Figure  1 1  shows  both  timelines. 
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7.  Black-box  Case  lc  Configuration 

To  see  the  effect  of  employing  both  crew  members  independently,  we  have 
modified  Case  1  by  making  all  odd  numbered  tasks  solo  (except  Task  1,  the  airlock 
egress),  leaving  the  even  numbered  tasks  tandem.  All  other  inputs  and  model  parameters 
remain  the  same  as  those  in  Case  1 . 

8.  Black-box  Case  lc  Results 

One  special  note  about  this  variant  of  the  test  case  is  that  making  half  the  tasks 
solo  activities  means  there  is  time  to  complete  all  the  tasks  during  a  single  EVA.  Task 
selection  is  not  a  factor  and  the  optimization  is  related  to  sequencing  only. 

The  heuristic  solution  for  this  case  splits  the  crew  immediately,  sending  EV1  to 
worksite  A  immediately  to  perform  the  highest  priority  task.  EV2  translates  to  the  nearest 
worksite  (C),  performs  the  only  solo  task  at  that  location,  then  moves  to  worksite  B  to 
perform  solo  tasks  until  such  time  as  EV1  can  arrive.  Both  crew  members  continue  to 
work  on  solo  tasks  until  all  are  complete.  In  order  to  synchronize  both  crew  members,  an 
idle  period  must  be  incurred,  after  which  they  perform  the  tandem  tasks  together.  Tandem 
tasks  are  completed  first  at  worksite  B,  then  worksite  C.  This  solution  yields  an  objective 
score  of  43.42  value  units.  The  heuristic  and  EPM  summary  timelines  for  this  test  case 
are  shown  in  Figure  12. 

The  EPM  optimal  solution  exhibits  a  subtly  different  approach  to  this  case.  It  does 
not  split  the  crew  right  away,  but  instead  sends  them  both  to  worksite  C  to  perfonn  the 
three  tandem  tasks.  It  then  leaves  EV1  at  worksite  C  to  perfonn  the  remaining  solo  task 
there  (Task  13),  while  EV2  translates  to  worksite  B  to  perform  a  solo  task.  Upon 
completion  of  Task  13,  EV1  translates  to  worksite  B.  This  sequencing  allows  the  crew 
member's  timelines  remain  synchronized,  and  tandem  tasks  at  worksite  B  may  be 
initiated  without  any  preceding  idle  time.  When  all  three  tandem  tasks  at  this  location  are 
complete,  EV2  is  sent  to  worksite  A  to  perfonn  Task  5,  while  EV1  completes  the 
remaining  solo  tasks  at  worksite  B.  The  20  minute  idle  time  that  must  occur  somewhere 
in  this  scenario  is  thus  left  to  the  very  end  of  the  EVA.  This  solution  results  in  an 
objective  score  of  43.43  value  units.  While  that  is  only  slightly  higher  than  the  heuristic 

65 


solution,  the  practical  difference  is  fairly  dramatic  in  favor  of  the  EPM  solution.  (The 
small  difference  indicates  the  weighing  factors  in  the  optimization  model  may  need  be 
revisited  to  ensure  this  highly  desirable  solution  is  more  clearly  differentiated  from  other 
solutions,  but  we  do  not  perform  that  change  here.)  The  EPM  solution  trades  performing 
Task  5  earlier  for  moving  the  idle  time  penalty  to  the  end  of  the  timeline.  It  is  very  good 
practice  to  move  idle  time  as  late  as  possible.  MOD  planners  have  a  motto  that  says  "you 
should  always  leave  runway  in  front  of  you,"  meaning  "do  not  wait  to  do  something  if 
you  might  later  regret  not  using  that  time."  That  is  exactly  what  the  EPM  has  done  by 
delaying  the  idle  time  as  long  as  possible.  The  good  sense  of  this  approach  can  be 
demonstrated  if  we  imagine  that  during  the  execution  of  the  heuristic  timeline,  for 
example,  Task  1 1  took  15  minutes  longer  than  expected.  EV2,  who  had  been  idle  waiting 
for  the  completion  of  Task  11,  now  is  faced  with  another  15  minutes  of  idle  time  before 
any  other  tasks  can  be  perfonned.  In  some  cases,  such  a  scenario  could  seriously 
compromise  the  success  of  an  EVA. 
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9.  Black-box  Case  Id  Configuration 

Case  Id  is  intended  to  demonstrate  the  effect  of  defining  allowable  time  windows 
for  certain  tasks.  For  this  case  we  start  with  black-box  test  Case  lc  and  add  the  constraint 
that  all  tasks  at  worksite  C  must  take  place  during  orbital  night.  This  type  of  constraint 
could  be  imposed  because,  for  example,  the  tasks  (or  their  locations)  dictate  that  solar 
array  rotary  joints  be  parked  (rotation  is  temporarily  stopped).  We  can  envision  a  scenario 
in  which  the  ISS  power  consumption  profile  requires  all  solar  arrays  to  be  in  sun  tracking 
mode  during  orbital  day  instead  of  a  less  efficient  parked  position.  In  such  a  situation,  the 
array  may  only  be  parked  at  night  and  our  EVA  timeline  must  comply  with  the 
requirement. 

In  addition  to  the  timing  constraint  placed  on  the  tasks  at  worksite  C,  we  stipulate 
that  Task  5  involves  mating  and/or  de-mating  toxic  fluid  connectors.  This  brings  with  it 
two  more  timing  constraints:  (1)  the  task  can  only  occur  during  periods  when  the  thermal 
environment  has  stabilized  (to  avoid  large  pressure  changes  in  the  fluid  lines  caused  by 
temperature  changes),  and  (2)  the  task's  completion  time  must  be  such  that  sufficient  time 
remains  in  the  EVA  to  perform  a  bake-out  if  EMU  contamination  is  suspected.  The 
nature  of  Task  5  is  not  unprecedented;  the  ISS  utilizes  100%  anhydrous  ammonia  in  its 
external  thermal  control  system  (NASA,  2011a)  and  connectors  in  this  system  must  be 
manipulated  during  some  EVA  tasks,  including  some  Big  12  contingency  EVA  tasks.  In 
fact,  leaks  from  exactly  such  a  system  during  one  of  the  pump  module  replacement  EVAs 
in  2010  (NASA,  2010b)  forced  a  bake-out  to  be  executed  to  prevent  toxic  material  from 
being  introduced  into  the  ISS  cabin  atmosphere  (Harwood,  2010). 

As  discussed  in  Chapter  II,  there  is  a  sunrise  and  sunset  every  45  minutes  at  the 
orbital  velocity  of  the  ISS,  thus  the  tasks  at  worksite  C  must  be  parsed  into  the  windows 
that  correspond  to  night  periods.  Further,  the  thermally  stable  conditions  needed  for  Task 
5  require  that  it  not  be  scheduled  during  or  immediately  following  a  sunrise  or  sunset. 
The  exact  synchronization  of  the  crew  workday  with  sunset  and  sunrise  times  varies  and 
is  not  typically  known  in  exactitude  until  relatively  close  to  the  time  of  EVA  execution. 
We  estimate  the  night  periods  in  terms  of  EVA  PET  windows  in  general,  allowing  for 

refinement  when  the  true  synchronization  becomes  clear.  For  this  test  case,  we  will  use 
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the  example  orbital  sunrise  and  sunset  times  in  Table  9  to  create  our  time  windows.  We 
have  created  the  allowable  time  windows  for  Task  5  by  assuming  thermal  stabilization 
takes  15  minutes  following  each  sunrise  and  sunset  and  also  included  a  five  minute  pad 
before  sunrise  and  sunset  as  a  safety  margin.  Recall  that  the  latest  bake-out  time 
parameter,  5 ,  is  the  latest  PET  at  which  toxic  tasks  must  be  completed.  Here  it  is 
calculated  using  a  30-minute  bake-out  period  and  the  orbital  timing  in  the  table. 


Orbital  Day /Night 
Times  in  PET  (H:MM) 

Thermally  Stable 
Periods  in  PET  (H:MM) 

Latest  Bake-out 

Time,  5,  in  PET 
(H:MM) 

Sunset 

Sunrise 

Start 

End 

0:15 

1:00 

0:00 

0:10 

5:05 

1:45 

2:30 

0:30 

0:55 

3:15 

4:00 

1:15 

1:40 

4:45 

5:30 

2:00 

2:25 

6:15 

7:00 

2:45 

3:10 

3:30 

3:55 

4:15 

4:40 

5:00 

5:25 

5:45 

6:10 

6:30 

6:55 

Table  9.  Time  parameters  for  black-box  test  case  id 


10.  Black-box  Case  Id  Results 

Case  id  is  a  much  more  difficult  one  for  a  human  planner  to  optimize  because  of 
the  increased  complexity.  Utilizing  basic  heuristics,  a  feasible  plan  is  created  in  relatively 
short  order  (40  minutes),  but  the  EPM  solution  proves  far  superior.  The  model  solution 
has  a  substantially  higher  objective  score  and  again  stands  up  extremely  well  to  common 
sense  analysis.  The  resulting  summary  timelines  in  Figure  13  demonstrate  that  while  a 
human  planner  tends  to  think  linearly  about  the  problem,  using  small  segments  of  idle 
time  throughout  the  EVA  to  address  the  many  timing  constraints,  the  model  is  able  to 
assess  all  possible  options  holistically.  This  allows  the  EPM  solution  to  gather  all  the 
required  idle  time  into  one  contiguous  segment  at  the  very  end  of  the  EVA,  while  the 
heuristic  timeline  includes  five  distinct  idle  periods.  The  result  of  the  EPM's  ability  to 
consolidate  this  idle  time  is  that  it  is  able  to  accommodate  all  tasks  and  provide  a  full  35 
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minutes  of  usable  time  at  the  end  of  the  EVA.  The  heuristic  solution  not  only  results  in 
idle  time  that  is  not  very  useful  due  to  its  scattershot  nature,  but  also  forces  the  omission 
of  one  of  the  solo  tasks  at  worksite  B. 
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Figure  13.  Black-box  test  case  Id  timelines 
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11.  Black-box  Testing  Summary 

The  black-box  testing  scheme  confirms  that  the  EPM  produces  credible  results 
that  match  or  exceed  the  results  developed  by  a  human  (albeit  not  expert)  planner  in  both 
objective  value  and  common-sense  assessment.  The  cases  have  been  kept  exceedingly 
simple  in  order  to  facilitate  easy  discussion  and  to  allow  a  non-expert  planner  to  make 
educated  heuristic  solutions  in  reasonably  short  time  periods.  Table  10  gives  some 
comparative  statistics  related  to  the  heuristic  solutions  to  the  test  cases  versus  the  model 
output. 


Black-box 

Test  Case 

Number 

Objective  Value 

Priority  Value  of 
Omitted  Tasks 

EVA  Duration  (H:MM) 

Idle  Time 

Total  (H:MM) /Type 

Solve  Time  (H:MM) 

Heuristic 

EPM 

Heuristic 

EPM 

Heuristic 

EPM 

Heuristic 

EPM 

Heuristic 

EPM 

1 

46.44 

52.52 

6 

3 

6:15 

6:20 

0:00/  na 

0:00/  na 

0:10 

10:54 

la 

52.74 

52.74 

6 

6 

6:15 

6:15 

0:00/  na 

0:00/  na 

0:10 

0:22 

lb 

40.34 

40.35 

9 

9 

6:20 

6:20 

0:00/  na 

0:00/  na 

0:15 

0:10 

lc 

43.42 

43.43 

0 

0 

5:50 

5:50 

0:20/ 

Condensed 

mid-EVA 

0:20/ 

Condensed 

at  End 

0:20 

1:14 

Id 

41.31 

43.36 

2 

0 

6:20 

6:25 

0:40/ 

Scattered 

0:35/ 

Condensed 

at  End 

0:40 

3:55* 

*  Solution  uses  CPLEX  "opportunistic"  parallel  mode  (all  other  cases  employ  deterministic  parallel  mode) 


Table  10.  Heuristic  vs.  EPM  output  comparison  for  black-box  test  cases 


An  unexpected  benefit  of  the  test  series  is  that  it  exposed  performance  issues  with 
the  EPM  model.  Table  10  includes  the  solution  times  for  each  case  and  reveals  that 
solution  times  have  a  large  variation,  but  tend  to  be  lengthy.  Trivial  changes  to  model 
inputs,  such  as  changing  the  priority  value  of  a  single  task,  sometimes  results  in  dramatic 
and  unpredictable  variations  in  solve  time  -  even  in  deterministic  modes  (see  below).  To 
address  the  overall  speed  of  the  model  as  formulated,  several  CPLEX  performance  tuning 
techniques,  advised  in  Gregory  (2008),  have  been  attempted  for  some  of  the  cases 
(notably  Case  Id).  These  techniques  include  the  employment  of  up  to  seven  parallel 
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threads  in  "opportunistic"  mode,  enabling  aggressive  probing,  and  utilizing  the  feasibility 
pump  heuristic.  Empirical  evaluation  of  these  modifications  indicate  some  benefit  is 
realized,  although  no  attempt  has  been  made  to  prove  this  fact.  In  using  the  parallel 
opportunistic  mode  (vice  deterministic)  solution  times  may  vary  even  with  identical 
inputs,  making  comparisons  very  difficult. 

The  black-box  test  series  also  exposes  that  the  consolidation  and  placement  of  idle 
time  is  one  of  the  most  substantial  strengths  of  the  EPM.  During  initial  development  of 
the  optimization  model,  this  was  not  necessarily  a  specific  goal.  Demonstrating  this 
capability  has  not  been  the  goal  of  black-box  testing,  but  its  emergence  in  the  test  results 
is  significant.  There  are  substantial  benefits  to  this  capability  that  have  real  value  in  EVA 
planning. 
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IV.  PROOF-OF-CONCEPT  EVALUATION 


The  testing  program  described  in  Chapter  III  proves  that  mathematical 
combinatorial  optimization  can  be  used  to  create  EVA  timelines  that  include  a 
comprehensive  consideration  of  trade-offs  and  constraints. 

This  chapter  addresses  the  value  of  the  EPM  concept  to  develop  timelines  (and 
alternatives)  for  actual  EVAs  under  current  development,  investigating  the  usefulness  of 
an  optimization  model  to  alleviate  some  of  the  manual  burden  of  creating  initial  and 
follow-on  timelines.  Although  the  number  of  test  cases  is  very  limited,  we  feel  that  these 
use-scenarios  are  representative  of  real-world  planning  situations  and  provide  a  valid 
basis  for  assessment  of  the  EPM  by  expert  planners. 

A.  METHODOLOGY 

As  discussed  in  Chapter  III,  evaluation  of  EVA  timelines  is  largely  subjective  and 
by  extension,  evaluation  of  the  EPM  is  also  subjective.  Understanding  this,  we  have 
based  our  proof-of-concept  assessment  on  (1)  comparisons  of  EPM  results  to  expert 
developed  timelines  and  (2)  expert  opinions  regarding  EPM  results  and  potential  utility. 

We  have  been  able  to  work  with  EVA  planning  experts  to  gather  the  necessary 
real-world  data  to  have  the  EPM  independently  create  two  EVA  plans  in  parallel  with 
their  traditional  development  so  the  two  results  can  be  compared.  Recalling  that  the 
planning  process  requires  many  "what-if  assessments  and  revisions  to  arrive  at 
consensus  regarding  which  tasks  will  be  included  in  an  EVA,  when  they  will  occur,  and 
the  opportunity  costs  (e.g.,  which  tasks  will  be  omitted  or  moved),  we  have  modeled  and 
evaluated  reasonable  alternatives  to  each  of  the  cases. 

We  have  also  demonstrated  the  EPM  to  experts  and  obtained  their  opinions  about 
its  usefulness.  The  data  are  organized  into  sections,  one  each  to  describe  the  EVA 
development  cases.  Expert  evaluations  are  summarized. 

The  reader  is  cautioned  that  many  tasks  and  locations  involved  in  the  EVA 
development  cases  contain  acronyms  which  are  not  defined  unless  their  definitions  are 
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important  to  a  basic  understanding  of  the  scenario.  In  most  situations,  this  level  of  detail 
is  not  needed  and  the  acronyms  are  simply  part  of  the  task  title.  To  avoid  confusion,  task 
names  are  presented  in  italics  when  discussed  in  the  text. 

B.  LEE  R&R  EVA  SCENARIOS 

The  LEE  is  a  component  of  the  space  station  robotic  manipulator  system 
(SSRMS)  that  allows  the  robotic  arm  to  grab  onto  grapple  fixtures  mounted  on  large 
ORUs  and  the  ISS  structure.  There  are  two  LEEs  on  the  SSRMS,  one  on  each  end.  The 
LEE  R&R  EVA  is  a  contingency  EVA  being  planned  in  the  event  a  LEE  fails  and  needs 
to  be  replaced.  A  spare  LEE  is  pre -positioned  at  a  stowage  location  on  the  exterior  of  the 
ISS.  Since  this  is  a  single-purpose  EVA,  the  planning  problem  is  focused  on  ordering  of 
and  crew  assignment  to  tasks.  Essentially,  the  tasks  are  steps  in  a  larger  "procedure."  The 
combined  duration  of  all  the  tasks  is  short  enough  to  fit  within  a  6.5-hour  EVA, 
eliminating  the  need  to  omit  any  tasks  due  to  lack  of  time.  There  are,  however,  extensive 
precedence  relationships  associated  with  the  tasks.  Additionally,  there  are  many  tandem 
tasks  and  tasks  that  involve  movement  from  one  worksite  to  another  (i.e.,  different 
starting  and  ending  location).  This  scenario  has  only  one  task  which  is  constrained  by 
time:  Install  LEE  is  assigned  a  bingo  time  of  5:05  PET.  The  full  set  of  raw  data  for  this 
EVA  scenario,  referred  to  as  LEE  R&R  EVA  (original),  has  been  provided  by  the  lead 
planner  (F.  Sabur,  personal  communication,  June  27,  2012),  and  can  be  found  in 
Appendix  A.  The  EPM  solve  time  for  the  two  scenarios  in  this  section  are  somewhat 
capricious,  ranging  from  18  minutes  for  the  original  scenario  to  several  hours  for  the 
alternate  scenario. 

There  are  very  few  possible  feasible  solutions  to  this  EVA  plan  because  of  the 
high  interaction  level  between  all  the  tasks.  Figure  14  shows  the  expert-generated, 
heuristic  solution  at  the  top  and  the  EPM  optimal  solution  in  the  middle.  The  EPM  is 
successful  in  duplicating  the  expert  solution. 

To  add  some  variability  to  this  planning  problem,  some  additional  tasks  unrelated 
to  the  LEE  R&R  activity  are  added.  This  is  commonly  done  by  the  program  customer 
when  an  EVA  has  extra  time  available,  as  this  one  does.  The  modified  scenario  is 
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referred  to  as  LEE  R&R  EVA  (alternate).  We  perform  a  second  EPM  run  with  three  new 
tasks  included  whose  characteristics  are  based  on  three  tasks  that  were  requested  to  be 
added  to  ISS  EVA  18  three  weeks  before  its  execution.  The  alternate  task  data  are  shown 
in  Appendix  B.  The  EPM  is  successful  in  accommodating  one  of  the  three  additional 
tasks  while  extending  the  EVA  by  36  minutes  over  the  baseline  case  (see  Figure  14, 
bottom).  The  inclusion  of  more  tasks  is  limited  primarily  by  the  long  distances  between 
the  worksites  of  the  LEE  R&R  and  the  new  tasks. 

Even  though  these  results  were  fairly  predictable  given  the  constraint  that  all  LEE 
R&R  tasks  must  be  completed  before  any  of  the  new  tasks  could  be  scheduled,  the  EPM's 
ability  to  handle  such  cases  has  been  successfully  demonstrated. 
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LEE  R&R  (Original)  EPM  Optimal  Solution 
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LEE  R&R  (Alternate)  EPM  Optimal  Solution 
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Figure  14.  LEE  R&R  EVA  timelines 
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C.  EVA  "A"  SCENARIOS 

EVA  “A”  is  in  the  early  planning  stages  for  execution  in  2013  or  2014.  It  is  a 
more  typical  ISS  assembly  and  maintenance  EVA,  driven  by  the  need  to  accomplish  a 
“to-do  list”  of  tasks  requested  by  the  ISS  program  customer.  This  EVA  represents  a  much 
different  planning  scenario  than  the  LEE  R&R.  Here,  the  number  and  duration  of 
requested  tasks  exceed  the  time  available  in  a  single  EVA.  All  of  the  tasks  are  unique  and 
independent,  meaning  no  precedence  relationships  exist,  and  all  tasks  are  solo.  Two  tasks 
requested  for  this  EVA  have  time  window  constraints.  The  first,  MTRA  Install,  is 
constrained  by  a  four-hour  thennal  clock  which  starts  at  the  beginning  of  the  EVA;  the 
second,  MISSE  8  Retrieve,  must  be  scheduled  such  that  the  first  20  minutes  of  the  task 
occur  during  daylight  (so  that  photographs  can  be  taken).  Another  interesting  aspect  of 
this  EVA  is  that  since  all  the  tasks  are  independent  of  each  other,  they  all  use  a  unique  set 
of  tools  and  equipment.  Owing  to  limited  carrying  capacity,  the  crew  members  must 
translate  to  the  Airlock  to  obtain  the  necessary  tools  and  equipment  at  the  beginning  of 
each  task  and  return  there  to  drop  them  off  at  the  end.  As  such,  for  most  of  the  tasks,  the 
beginning  and  ending  location  is  the  Airlock.  This  nuance  of  the  tasks  eliminates  some 
flexibility  the  EPM  could  use  to  optimize  their  scheduling,  but  presents  an  interesting 
planning  scenario.  The  full  set  of  raw  task  data  associated  with  this  EVA,  has  been 
provided  by  the  lead  planners  (J.  Kagey  &  A.  Battocletti,  personal  communication, 
August  23,  2012),  and  can  be  found  in  Appendix  C.  Figure  15  shows  the  current  expert- 
developed  timeline,  labeled  "heuristic"  along  with  the  EPM  optimal  solution.  The  EPM 
solve  time  for  each  of  the  scenarios  in  this  section  are  highly  satisfactory,  ranging 
between  two  and  four  minutes.  The  subsections  below  detail  some  of  the  alternatives 
explored  using  EPM  and  the  conclusions  we  have  drawn  from  the  results. 

1.  Task  Selection 

The  first  challenge  of  this  planning  scenario  is  to  select  the  tasks  that  will  be 
omitted  from  the  plan  since  there  is  not  enough  time  for  all  requested  tasks.  The  expert 
planners  have  omitted  two  tasks,  JEM-EF  Fwd  Camera  and  MLM Ethernet  Cable  Install, 
because  they  are  the  two  lowest  priority  tasks.  The  EPM  makes  the  same  omissions  due 
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in  part  to  the  lower  priority  value  of  the  tasks,  but  also  because  of  their  relative  length 
compared  to  similarly  prioritized  tasks.  The  Node3  Fwd/Aft  CBM  Prep  and  FGB  PDGF 
Troubleshooting  tasks,  which  have  priority  values  just  10%  greater  than  JEM-EF  Fwd 
Camera,  are  scheduled  instead  -  primarily  because  they  have  durations  that  are  25%  and 
50%  shorter,  respectively. 

2.  Priority  Changes 

To  examine  the  effect  of  changing  priorities,  we  simulate  the  common  situation  of 
the  program  customer  mandating  that  a  specific  task  be  added  to  an  EVA  in  development. 
Typically,  a  negotiation  occurs  in  these  situations,  and  the  ability  to  generate  alternative 
timelines  is  important  to  inform  stakeholder  decisions.  As  described  in  Chapter  I, 
developing  these  alternatives  is  time  consuming  for  the  planners  and  there  usually  is  not 
adequate  time  to  explore  all  possible  options. 

Our  simulation  of  this  scenario  involves  one  change  to  the  previous  EVA  "A" 
model  inputs:  flagging  JEM-EF  Fwd  Camera  as  mandatory.  The  bottom-most  timeline  in 
Figure  15  is  the  resulting  optimal  solution.  An  interesting  effect  of  this  change  is  that  the 
EPM  does  not  simply  remove  the  next-lowest  priority  task  from  the  plan.  Instead  it 
removes  Z1  Jumper  Route/Install,  the  fourth-highest  priority  task.  In  doing  so,  however, 
it  replaces  it  with  both  the  now-mandatory  task  and  also  the  previously  omitted  MLM 
Ethernet  Cable  Install.  If  this  outcome  is  also  unsatisfactory  to  the  program  customer, 
other  input  parameters  may  be  adjusted  in  turn,  conveying  the  trade-offs  and  costs  of  new 
or  updated  requirements. 
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3.  Day/Night  Phasing 

One  immediate  advantage  of  utilizing  the  EPM  is  clear  when  considering  the 
EVA  "A"  case:  the  ability  to  plan  for  the  daylight  constraints  on  the  MISSE  8  Retrieve 
task.  Since  the  execution  date  of  the  EVA  is  unknown  at  this  time,  it  is  impossible  for  the 
planners  to  know  what  the  actual  day/night  timing  will  be  with  respect  to  PET  (referred 
to  as  "phasing").  The  planners  have  no  choice  but  to  ignore  this  factor  for  the  time  being 
and  create  their  EVA  plan  as  if  the  constraint  did  not  exist.  This  approach  carries  the  risk 
that  when  the  actual  day/night  phasing  becomes  known,  it  could  result  in  substantial 
disruption  to  the  timeline.  Such  a  perturbation  must  then  be  addressed  at  a  relatively  late 
stage  of  the  planning  process.  The  EPM  allows  the  planners  to  examine  a  range  of 
different  day/night  phasing  to  assess  the  impact  it  has  on  the  optimal  plan  far  earlier  in 
the  process. 

To  investigate  these  effects,  several  day/night  phasing  cases  have  been  tested. 
Figure  16  shows  three  timelines;  all  are  optimal  plans  given  their  respective  phasing, 
which  is  defined  by  the  PET  of  the  first  sunrise  during  the  EVA.  Optimal  timelines 
corresponding  to  first  sunrises  at  PET  of  30,  60,  and  90  minutes  are  shown.  A  notable 
conclusion  we  can  draw  from  these  alternatives  is  that  the  heuristic  solution,  which 
schedules  MISSE  8  Retrieve  at  2:00  PET,  is  only  feasible  in  one  of  these  cases  (sunrise  at 
0:30  PET)  and  even  in  that  case  it  is  not  optimal.  This  tells  us  that  it  is  highly  likely  the 
planners  will  have  to  adjust  the  timing  of  this  task  eventually.  Knowing  that,  it  is 
important  to  observe  that  although  the  MISSE  8  Retrieve  task  is  the  only  one  impacted  by 
day/night  phasing,  the  changes  to  the  timeline  extend  well  beyond  just  the  timing  of  this 
one  task.  Without  a  capability  to  examine  all  the  possible  outcomes  ahead  of  time,  a 
human  planner  may  be  forced  to  wait  for  the  phasing  information  to  become  available 
and  then  implement  the  suboptimal  solution  of  simply  sliding  the  task  start  time  forward 
or  back  by  enough  minutes  to  make  the  lighting  conditions  acceptable.  In  taking  this 
approach,  they  would  be  inherently  diminishing  the  efficiency  of  the  EVA. 
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D.  EXPERT  EVALUATION  OF  EPM 

The  EPM  has  been  demonstrated  for  current  and  former  EVA  planning  experts  in 
order  to  solicit  their  opinions  about  its  capabilities  and  usefulness.  These  demonstrations 
include  the  two  EVA  planning  scenarios  described  in  this  chapter  and  static  presentations 
of  the  EPM's  features  and  results.  Data  have  been  gathered  via  expert  survey 
questionnaires.  The  sample  size  is  limited  to  four  experts,  in  part  by  the  small  number  of 
such  experts  available,  and  also  due  to  ongoing  EVA  operations  fdling  their  schedules. 
As  a  result,  this  evaluation  is  not  presented  as  a  scientific  study,  but  rather  as  a 
generalized  indicator  of  the  potential  of  the  EPM  tool  and  areas  of  improvement. 

The  EPM  has  been  well  received  by  all  four  EVA  planning  experts  surveyed.  All 
indicate  they  would  be  inclined  to  utilize  such  a  tool  if  it  were  available.  They  rate  the 
timelines  produced  by  the  model  as  credible.  One  evaluator  points  to  preterition  in 
defining  input  data  as  a  cause  of  deficiencies  noted  in  the  resulting  plan.  When  asked  to 
evaluate  the  usefulness  of  the  EPM,  experts  rate  it  highest  (average  rating  of  4.33  on  a 
five-point  scale)  in  three  categories:  (1)  plan  development  and  trade-space  evaluations, 
(2)  preparing  for  stakeholder  negotiations,  and  (3)  increased  ability  to  assess  alternatives. 
One  expert  noted: 

I  would  use  the  tool  primarily  during  discussions  with  the  ISS  Program 
and  Flight  Director  Office  [a  key  stakeholder  within  MOD],  In  my 
experience,  they  like  to  see  many  options  and  sometimes  think  arranging 
[the  plan]  a  little  different  would  create  more  [free  time  in  the  plan].  This 
tool  would  have  made  those  demonstrations  much  quicker  and  less  work 
involved  for  the  EVA  team.  It  may  also  convince  upper  level  management 
that  if  you  really  want  all  those  tasks  completed,  you  need  to  schedule 
another  EVA. 

Another  expert  acknowledges  the  potential  of  EPM  to  save  time  and  expense  in 
initial  timeline  development  for  specific  types  of  EVAs,  stating: 

For  EVAs  with  one  long  task  and  highly  constrained  sequencing,  the  tool 
would  not  be  as  useful.  But  it  would  be  useful  in  early  EVA  plan 
development  when  assessing  how  to  schedule  smaller  tasks  across  a  single 
or  multiple  EVA.  In  many  cases  the  EVA  planners  scuba  dive  or  perform 
a  suited  NBL  run  to  evaluate  proposed  timelines.  This  can  be  an  iterative 
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process  as  we  develop  a  timeline.  Having  a  good  starting  point  would  help 
reduce  the  number  of  iterations  and  could  help  illustrate  specific 
trades/options. 

The  quote  above  agrees  well  with  our  observations  of  the  two  distinct  types  of 
EVA  planning  scenarios  described  in  this  chapter.  The  LEE  R&R  EVA  is  a  "highly 
constrained  sequencing"  scenario  where  the  EPM  output  offers  little  more  than  matching 
the  expert-developed  timeline,  while  EVA  "A"  is  a  less  constrained  problem  and 
demonstrates  the  power  of  the  EPM  to  identify  and  assess  alternatives. 

The  EPM  is  rated  lower  in  its  perceived  ability  to  save  time  in  plan  development, 
largely  due  to  the  data  entry  requirements  and  unpolished  user  interface.  The  user 
interface  and  manual  entry  of  task  data  is  noted  in  multiple  expert  evaluations  as  a 
weakness,  one  stating:  "I  think  the  longest  pole  is  getting  all  of  the  initial  data  into  the 
system.  If  it  is  not  too  long  then  I  think  this  could  be  real  [s/c]  helpful."  Another 
respondent  points  out: 

Inputting  the  tasks  and  restrictions  could  be  more  user  friendly.  Being  able 
to  save  these  tasks  to  a  database  so  future  runs  could  pick  and  choose 
already  developed  tasks  along  with  new  items  would  also  be  helpful. 

Given  the  general  reluctance  to  adopt  new  tools  and  embrace  "automation"  in 
processes  that  have  historically  been  very  hands-on  and  the  fact  that  most  of  the 
deficiencies  noted  are  related  to  the  user  interface  and  not  the  core  capability  of  the  EPM, 
the  expert  evaluations  are  a  positive  sign  that  EPM  may  become  a  helpful  tool  in  the 
process  of  EVA  planning. 
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V.  FUTURE  WORK 


The  EPM  has  been  developed  to  a  proof  of  concept  level  as  part  of  this  research. 
The  model  has  proven  to  be  a  usable  tool  that  can  help  inform  decision  making  during 
EVA  planning  even  in  its  current  form.  There  are  many  improvements  that  can,  and 
should,  be  made  to  the  model  if  its  development  is  to  continue  with  the  goal  of 
operational  use. 

A.  ADDITIONAL  FUNCTIONALITY 

We  use  the  tenn  functionality  to  refer  to  the  real-world  planning  considerations 
that  are  implemented  by  the  model.  Precedence  relationships  and  asynchronous 
translation  times  are  examples  of  two  functions  in  the  current  EPM.  There  are  many  other 
functions  that  could  be  added  to  the  model,  some  of  which  (e.g.,  task  subdivision)  are 
extraordinarily  difficult  problems.  This  section  focuses  on  functionality  that  could  be 
added  in  a  follow-on  revision  rather  than  on  the  litany  of  capabilities  that  could  be  added 
in  the  more  distant  future. 

1.  Tool  Constraints 

Tools  are  an  extremely  important  part  of  EVA  planning  and  execution.  The 
current  EPM  does  not  address  tool  requirements  or  constraints  and  adding  this  capability 
would  be  a  major  enhancement.  This  functionality  could  include  a  limit  on  how  many 
tools  can  be  carried  at  once,  automatic  addition  of  tool  logistics  tasks  (for  instance, 
translating  to  a  tool  box  location  to  exchange  tools),  and  ensuring  that  a  unique  tool  is  not 
needed  by  one  crew  member  while  the  other  crew  member  is  using  it  elsewhere. 

2.  Task  Synergy 

Task  synergy  was  mentioned  in  Chapter  I  as  having  a  role  in  planning 
considerations.  It  was  not  implemented  because  in  the  current  model  architecture,  all 
tasks  considered  are  unique  and  individual.  They  can  only  be  related  to  each  other 
through  precedence.  In  reality,  tasks  can  be  interlinked  in  different  ways.  For  example, 
some  tasks  may  have  common  steps  which  can  yield  substantial  efficiency  gains  if  the 
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tasks  are  performed  adjacent  to  one  another  during  the  EVA.  To  envision  this,  consider 
three  tasks  whose  first  step  is  the  removal  of  the  same  thennal  cover.  In  the  current 
model,  each  of  the  tasks  would  be  entered  with  a  duration  that  includes  the  removal  and 
replacement  of  the  thermal  cover.  The  EPM  would  be  aware  of  only  one  efficiency:  that 
the  tasks  have  the  same  location.  However,  in  reality,  if  any  one  of  the  tasks  is  scheduled, 
the  other  two  would  be  less  time  consuming  when  performed  in  immediate  sequence  with 
it.  This  type  of  relation  is  more  difficult  to  implement  than  simple  precedence  because 
there  is  no  need  to  stipulate  the  order  in  which  they  occur  and  the  effect  of  them  being 
scheduled  "together"  is  a  reduction  in  the  duration  of  some  of  the  tasks. 

3.  Task  Exclusivity 

Task  exclusivity  is  another  way  in  which  tasks  can  be  linked.  This  category 
involves  groups  of  tasks  that  are  mutually  exclusive.  For  example,  consider  a  case  where 
three  camera  replacement  tasks  are  possible.  In  the  current  model,  they  become 
independent  tasks  which  have  no  relation  to  each  other.  However,  if  there  are  only  two 
spare  cameras  available,  then  only  two  of  the  three  tasks  may  be  scheduled.  The  ability  to 
eliminate  a  set  of  tasks  from  consideration  if  another  task  has  been  completed  would  be 
fairly  simple  to  add  in  a  future  version  of  the  EPM.  Conversely,  there  may  be  some  tasks 
that  should  always  be  perfonned  together  (although  not  necessarily  in  a  specific  order  or 
concurrently).  To  add  that  type  of  functionality,  a  set  of  tasks  would  become  mandatory  if 
and  only  if  another  task  or  tasks  have  been  scheduled. 

4.  Robotics  Integration 

Many,  if  not  most,  EVAs  employ  the  ISS  robotic  arm.  Robotics  may  be  used  to 
assist  the  crew  in  translating  across  long  distances,  help  them  reach  difficult  worksites,  or 
allow  the  positing  of  large  or  massive  objects.  Since  robotic  arm  integration  is  such  an 
important  part  of  EVA,  its  omission  from  the  first  version  of  the  EPM  leaves  the  potential 
for  significant  improvement.  In  most  of  the  cases  examined  for  this  research,  we  have 
found  that  robotic  arm  integration  can  be  mimicked  by  manipulating  translation  times  for 
locations  known  to  be  associated  with  robotics-assisted  tasks.  This  is  a  makeshift  fix  that 
is  inadequate  for  longer-term  use  and/or  more  realistic  employment  of  the  EPM. 
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B.  MODEL  PERFORMANCE 

We  have  observed  during  black-box  testing  and  in  proof-of-concept  runs  of  the 
EPM  that  its  performance  in  terms  of  solution  time  is  inadequate.  EPM  solve  times  are 
highly  variable  and  increased  dramatically  with  more  complicated  problems.  For 
complex  problems,  solve  times  in  the  24-hour  range  would  not  be  unexpected.  While  this 
is  not  necessarily  a  problem  for  the  generation  of  preliminary  plans  in  the  early  phases  of 
development,  it  could  rule  out  use  of  the  tool  closer  to,  or  in,  real-time.  Poor  perfonnance 
also  works  against  the  notion  that  an  expert  planner  could  use  the  model  to  generate  a 
candidate  timeline,  evaluate  it,  change  some  parameters  to  adjust  it,  then  re-run  the  model 
(and  repeat).  For  that  type  of  use  scenario  to  be  practicable,  solve  times  would  have  to  be 
in  four-hour  or  less  range  (to  facilitate  multiple  runs  in  a  single  work  day). 

There  are  many  options  to  improve  performance  of  the  model,  some  of  which 
have  been  explored  on  a  limited  basis  during  black-box  testing.  A  more  focused  effort  on 
altering  CLPEX  settings  to  tailor  performance  to  our  specific  model  could  yield  better 
results.  Exploring  the  use  of  other  solvers  should  also  be  undertaken.  Finally,  the  model 
could  be  revised  to  reduce  complexity  and/or  strengthen  the  formulation. 

C.  EASE  OF  USE 

To  facilitate  expert  user  acceptance  and  more  widespread  testing  of  future 
versions  of  the  EPM,  ease  of  use  could  be  improved.  In  the  current  version,  all  input  data 
are  entered  through  Microsoft  Excel  templates  via  10  independent  files  that  must  be 
populated  with  infonnation.  This  should  be  reduced  to  a  more  economical  set  of  input 
files  or  replaced  by  a  user  friendly  interface  for  data  entry,  possibly  supported  by  a 
database  of  existing  tasks  (and  other  problem  data)  as  suggested  by  one  of  the  surveyed 
planners.  The  addition  of  embedded  input  error  checks  and  validations  (for  example, 
ensuring  that  a  task's  duration  does  not  exceed  its  bingo  time),  would  be  a  beneficial 
refinement. 

The  output  of  the  model  is  another  area  where  usability  can  be  enhanced.  The  raw 
output  of  the  current  EPM  is  comprised  of  one  formatted  text  file  showing  the  PET  and 
tasks  for  each  crew  member  and  one  Excel  file  that  shows  the  tasks  along  with  idle  time 
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and  translations.  The  former  also  provides  a  list  of  which  input  tasks  have  been  omitted 
from  the  EVA.  The  Excel  output  file  is  used  to  more  readily  interface  with  an  Excel 
Visual  Basic  macro  that  produces  the  graphical  overview  timelines  seen  in  the  figures  of 
Chapters  III  and  IV.  These  graphical  views  are  commonly  used  by  the  planning  experts 
and  stakeholders.  This  process  requires  several  intermediate  steps,  which  could  be 
streamlined  to  improve  usability. 

D.  INTEGRATION  WITH  OTHER  AUTOMATED  PLANNING  TOOLS 

The  possible  integration  of  EPM  with  the  task  database,  hierarchical  task  net 
information,  and  resource  handling  algorithms  developed  by  TRACLabs  (described  in 
Chapter  II)  is  an  intriguing  possibility.  That  work  potentially  holds  the  key  to  reducing 
the  amount  of  manual  data  entry  required  for  the  EPM.  It  could  also  lead  to  enhancing  the 
EPM's  capabilities  in  areas  highlighted  above  (e.g.,  tool  constraint  management)  and  in 
new  areas  such  as  detailed  consideration  of  EMU  consumables.  Finally,  it  could  enable 
the  EPM  to  tackle  the  problem  of  task  subdivision. 
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VI.  CONCLUSION 


EVA  planning  is  a  highly  complex  process  requiring  a  high  level  of  expertise.  We 
have  developed  the  EPM,  a  MIP  that  optimizes  the  EVA  planning  sub-problems  of  task 
selection,  crew  assignment,  and  task  sequencing.  The  EPM  proves  the  concept  that 
formal  combinatorial  optimization  can  be  used  to  successfully  improve  the  efficiency  of 
EVA  timeline  development.  The  EPM  has  been  tested  extensively  both  to  verify  its 
functionality  and  its  usefulness  in  real-world  EVA  planning  situations.  It  has  been 
evaluated  by  EVA  planning  experts  who  cited  time  savings  in  plan  development  and 
especially  in  assessment  of  alternatives  as  major  reasons  they  would  want  to  use  the  tool. 

We  find  that  the  EPM,  while  necessarily  limited  in  its  initial  functionality,  is  able 
to  provide  complete  and  credible  overview  level  timelines  for  two  actual  EVAs  using 
only  raw  source  data.  We  also  find  that  it  is  capable  of  handling  alternative  planning 
scenarios  commonly  found  in  practice,  including  (1)  the  addition  of  extra  tasks  to  a 
developed  EVA  plan,  (2)  a  thorough  analysis  of  orbital  day/night  phasing  impacts  upon 
EVA  plans  with  tasks  sensitive  to  such  phasing,  and  (3)  the  changing  of  customer 
priorities  during  the  planning  process.  Furthermore,  the  EPM  has  demonstrated  enhanced 
trade-space  evaluation  by  its  ability  to  examine  all  feasible  permutations  of  task  selection, 
sequencing,  and  assignment  and  its  creation  of  EVA  plans  as  holistic  entities  rather  than  a 
series  of  sequential  decisions  as  a  human  planner  might. 

The  EPM  can  be  improved  in  multiple  ways.  Although  no  test  case  takes  more 
than  24  hours  to  reach  an  optimal  solution,  the  model's  solve-time  performance  is  found 
to  be  highly  variable  and  unpredictable.  For  example,  some  test  cases  take  more  than  ten 
hours  to  solve,  while  others  require  less  than  five  minutes.  We  have  identified  several 
other  improvement  areas  for  the  EPM,  including  added  functionality  and  friendlier  user 
interface. 
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APPENDIX  A:  LEE  R&R  EVA  RAW  DATA 


This  appendix  provides  data  tables  containing  the  raw  input  data  used  as  EPM 
input  for  the  LEE  R&R  EVA  planning.  These  data  have  been  gathered  via  personal 


communication  with  the  lead  EVA  planner,  F.  Sabur  (June  27,  2012). 


Priority 

DurEVl 

DurEV2 

Mandatory 

Tandem 

Airlock 

o 

X 

o 

I- 

FlasWindow 

FlasBingo 

BingoTime 

PVGF_Release_from_EP 

100 

5 

6 

0 

0 

0 

0 

0 

0 

0 

Pl_Worksite_Setup 

100 

30 

33 

0 

0 

0 

0 

0 

0 

0 

Remove_CLA 

100 

10 

11 

0 

0 

0 

0 

0 

0 

0 

Translate_Failed_LEE_to_ELCl 

100 

30 

30 

0 

1 

0 

0 

0 

0 

0 

Spare_LEE_Prep 

100 

45 

50 

0 

0 

0 

0 

0 

0 

0 

Stow_Failed_LEE_on_Temp_Stow_Ring 

100 

25 

25 

0 

1 

0 

0 

0 

0 

0 

Retrieve_Spare_Lee 

100 

40 

40 

0 

1 

0 

0 

0 

0 

0 

Translate_Spare_LEE_to_Pl_Worksite 

100 

30 

30 

0 

1 

0 

0 

0 

0 

0 

1  nstal  ICLA 

100 

10 

11 

0 

0 

0 

0 

0 

0 

0 

1  nstal  ILEE 

100 

30 

30 

0 

1 

0 

0 

0 

1 

305 

LEE_FSE_Cleanup 

100 

9 

10 

0 

0 

0 

0 

0 

0 

0 

Remove_Failed_LEE 

100 

30 

30 

0 

1 

0 

0 

0 

0 

0 

Cleanupjngress 

100 

30 

30 

1 

1 

1 

0 

0 

0 

0 

Egress_Setup 

100 

15 

15 

1 

1 

0 

0 

1 

0 

0 

Table  11.  Task  Data 
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Task 

Initial  Location 

Final  Location 

PVGF_Release_from_EP 

HTV 

HTV 

Pl_Worksite_Setup 

Columbus_WIF3 

Pl_Worksite 

Remove_CLA 

Pl_Worksite 

Pl_Worksite 

Translate_Failed_LEE_to_ELCl 

Pl_Worksite 

ELC1 

Spare_LEE_Prep 

ELC1 

ELC1 

Stow_Failed_LEE_on_Temp_Stow_Ring 

ELC1 

ELC1 

Retrieve_Spare_Lee 

ELC1 

ELC1 

Translate_Spare_LEE_to_Pl_Worksite 

ELC1 

Pl_Worksite 

1  nstal  l_CLA 

Pl_Worksite 

Pl_Worksite 

1  nstal  1  LEE 

Pl_Worksite 

Pl_Worksite 

LEE_FSE_Cleanup 

ELC1 

ELC1 

Remove_LEE 

Pl_Worksite 

Pl_Worksite 

Cleanupjngress 

Airlock 

Airlock 

Egress_Setup 

Airlock 

Airlock 

Table  12.  Task  Locations 


Predecessor 

Successor 

Pl_Worksite_Setup 

Remove_CLA 

Remove_Failed_LEE 

Translate_Failed_LEE_to_ELCl 

Remove_CLA 

Translate_Failed_LEE_to_ELCl 

Translate_Failed_LEE_to_ELCl 

Stow_Failed_LEE_on_Temp_Stow_Ring 

Spare_LEE_Prep 

Retrieve_SpareJ.ee 

Translate_Failed_LEE_to_ELCl 

Retrieve_Spare_Lee 

Retrieve_Spare_Lee 

Translate_Spare_LEE_to_Pl_Worksite 

Remove_CLA 

1  nstal  l_CLA 

Remove_Failed_LEE 

lnstall_CLA 

Translate_Spare_LEE_to_Pl_Worksite 

lnstall_CLA 

1  nstal  l_C  LA 

lnstall_LEE 

Translate_Spare_LEE_to_Pl_Worksite 

lnstall_LEE 

Retrieve_Spare_Lee 

LEE_FSE_Cleanup 

Stow_Failed_LEE_on_Temp_Stow_Ring 

LEE_FSE_Cleanup 

Translate_Spare_LEE_to_Pl_Worksite 

LEE_FSE_Cleanup 

Remove_CLA 

Remove_Failed_LEE 

Pl_Worksite_Setup 

Remove_Failed_LEE 

PVGF_Release_from_EP 

Remove_Failed_LEE 

Stow_Failed_LEE_on_Temp_Stow_Ring 

Retrieve_Spare_Lee 

Table  13.  Precedence  Relationships 
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To 

From 

Airlock 

HTV 

ELC1 

Pl_Wrkst 

Col_WIF3 

Airlock 

0 

10 

15 

13 

8 

HTV 

10 

0 

20 

13 

2 

ELC1 

15 

20 

0 

13 

20 

Pl_Wrkst 

13 

13 

13 

0 

13 

Col_WIF3 

8 

2 

20 

13 

0 

Table  14.  Translation  Times 


tmin 

tmax 

wl 

Egress_Setup 

0 

30 

Table  15.  Task  Time  Windows 


95 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


96 


APPENDIX  B:  LEE  R&R  EVA  RAW  DATA  (ALTERNATE) 


This  appendix  provides  data  tables  containing  the  raw  input  data  used  as  EPM 
input  for  the  alternate  LEE  R&R  EVA  planning.  These  data  have  been  gathered  via 
personal  communication  with  the  lead  EVA  planner,  F.  Sabur  (August  13,  2012).  Only 


tables  with  changes  from  the  baseline  LEE  R&R  case  are  shown. 


Priority 

DurEVl 

DurEV2 

Mandatory 

Tandem 

Airlock 

Toxic 

FlasWindow 

FlasESingo 

ESingoTime 

PVGF_Release_from_EP 

100 

5 

6 

0 

0 

0 

0 

0 

0 

0 

Pl_Worksite_Setup 

100 

30 

33 

0 

0 

0 

0 

0 

0 

0 

Remove_CLA 

100 

10 

11 

0 

0 

0 

0 

0 

0 

0 

Translate_Failed_LEE_to_ELCl 

100 

30 

30 

0 

1 

0 

0 

0 

0 

0 

Spare_LEE_Prep 

100 

45 

50 

0 

0 

0 

0 

0 

0 

0 

Stow_Failed_LEE_on_Temp_Stow_Ring 

100 

25 

25 

0 

1 

0 

0 

0 

0 

0 

Retrieve_Spare_Lee 

100 

40 

40 

0 

1 

0 

0 

0 

0 

0 

Translate_Spare_LEE_to_Pl_Worksite 

100 

30 

30 

0 

1 

0 

0 

0 

0 

0 

Instal  l_CLA 

100 

10 

11 

0 

0 

0 

0 

0 

0 

0 

Instal  l_LEE 

100 

30 

30 

1 

1 

0 

0 

0 

1 

305 

LEE_FSE_Cleanup 

100 

9 

10 

0 

0 

0 

0 

0 

0 

0 

Remove_Failed_LEE 

100 

30 

30 

0 

1 

0 

0 

0 

0 

0 

Cleanupjngress 

100 

30 

30 

1 

1 

1 

0 

0 

0 

0 

Egress_Setup 

100 

15 

15 

1 

1 

0 

0 

1 

0 

0 

PMA2_Cover_lnstall 

60 

20 

20 

0 

1 

0 

0 

0 

0 

0 

SSRMS_Boom_Camera_Replace 

65 

35 

35 

0 

0 

0 

0 

0 

0 

0 

Retrieve_Mast_Camera 

50 

15 

15 

0 

0 

0 

0 

0 

0 

0 

Table  16.  Task  Data 
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Task 

Initial  Location 

Final  Location 

PVGF_Release_from_EP 

HTV 

HTV 

Pl_Worksite_Setup 

Columbus_WIF3 

Pl_Worksite 

Remove_CLA 

Pl_Worksite 

Pl_Worksite 

Translate_Failed_LEE_to_ELCl 

Pl_Worksite 

ELC1 

Spare_LEE_Prep 

ELC1 

ELC1 

Stow_Failed_LEE_on_Temp_Stow_Ring 

ELC1 

ELC1 

Retrieve_Spare_Lee 

ELC1 

ELC1 

Translate_Spare_LEE_to_Pl_Worksite 

ELC1 

Pl_Worksite 

1  nstal  l_CLA 

Pl_Worksite 

Pl_Worksite 

1  nstal  l_LEE 

Pl_Worksite 

Pl_Worksite 

LEE_FSE_Cleanup 

ELC1 

ELC1 

Remove_Failed_LEE 

Pl_Worksite 

Pl_Worksite 

Cleanupjngress 

Airlock 

Airlock 

Egress_Setup 

Airlock 

Airlock 

P  M  A2_Co  ve  r_l  nstal  1 

PMA2 

PMA2 

SSRMS_Boom_Camera_Replace 

S0_F2_WIF22 

S0_F2_WIF22 

Retrieve_Mast_Camera 

MT_WS4 

MT_WS4 

Table  17. 

Task  Locations 
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Predecessor 

Successor 

Pl_Worksite_Setup 

Remove_CLA 

Remove_Failed_LEE 

Translate_Failed_LEE_to_ELCl 

Remove_CLA 

Translate_Failed_LEE_to_ELCl 

Translate_Failed_LEE_to_ELCl 

Sto  w_Fai  1  ed_LEE_on_T  e  m  p_Sto  w_Ri  ng 

Spare_LEE_Prep 

Retrieve_Spare_Lee 

Translate_Failed_LEE_to_ELCl 

Retrieve_Spare_Lee 

Retrieve_Spare_Lee 

Translate_Spare_LEE_to_Pl_Worksite 

Remove_CLA 

1  nstal  l_CLA 

Remove_Failed_LEE 

lnstall_CLA 

Translate_Spare_LEE_to_Pl_Worksite 

1  nstal  l_CLA 

1  nstal  l_CLA 

Install  _LEE 

Translate_Spare_LEE_to_Pl_Worksite 

lnstall_LEE 

Retrieve_Spare_Lee 

LEE_FSE_Cleanup 

Stow_Failed_LEE_on_Temp_Stow_Ring 

LEE_FSE_Cleanup 

Translate_Spare_LEE_to_Pl_Worksite 

LEE_FSE_Cleanup 

Remove_CLA 

Remove_Failed_LEE 

Pl_Worksite_Setup 

Remove_Failed_LEE 

PVGF_Release_from_EP 

Remove_Failed_LEE 

Stow_Failed_LEE_on_Temp_Stow_Ring 

Retrieve_Spare_Lee 

1  nstal  l_LEE 

SSRMS_Boom_Camera_Replace 

Table  18.  Precedence  Relationships 


Airlock 

HTV 

ELC1 

PlJA/rkst 

Col_WIF3 

PMA2 

MT_WS4 

S0_WIF22 

Airlock 

0 

13 

10 

8 

10 

13 

32 

34 

HTV 

13 

0 

20 

10 

2 

2 

31 

33 

ELC1 

10 

20 

0 

10 

20 

22 

37 

41 

Pl_Wrkst 

8 

10 

10 

0 

10 

13 

17 

21 

Col_WIF3 

10 

2 

20 

10 

0 

2 

32 

34 

PMA2 

13 

2 

22 

13 

2 

0 

34 

36 

MT_WS4 

32 

31 

37 

27 

32 

34 

0 

24 

S0_WIF22 

34 

33 

41 

31 

34 

36 

24 

0 

Table  19.  Translation  Times 
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APPENDIX  C:  EVA  "A"  RAW  DATA 


This  appendix  provides  data  tables  containing  the  raw  input  data  used  as  EPM 
input  for  the  EVA  "A"  planning.  These  data  have  been  gathered  via  personal 
communication  with  the  lead  EVA  planners,  J.  Kagey  and  A.  Battocletti  (August  23, 


2012). 


Priority 

DurEVl 

DurEV2 

Mandatory 

Tandem 

Airlock 

<_> 

'x 

o 

i- 

FlasWindow 

FlasBingo 

BingoTime 

Egress_Setup 

1 

30 

30 

1 

1 

0 

0 

1 

0 

0 

MBS_Mast_CLPA_RR 

100 

90 

90 

0 

0 

0 

0 

0 

0 

0 

MTRAJn  stall 

90 

150 

150 

0 

0 

0 

0 

1 

0 

0 

MISSE_8_Retrieve 

95 

60 

60 

0 

0 

0 

0 

1 

0 

0 

N  o  d  e  3_F  w  d_Af  t_C  B  M_P  re  p 

50 

45 

45 

0 

0 

0 

0 

0 

0 

0 

Ro  u te_1553_Ca  b  1  e 

55 

60 

60 

0 

0 

0 

0 

0 

0 

0 

Remove_MBSU_MLI 

60 

45 

45 

0 

0 

0 

0 

0 

0 

0 

Cleanupjngress 

0 

45 

45 

1 

1 

1 

0 

0 

0 

0 

Zl_Jumper_Route_lnstall 

85 

75 

75 

0 

0 

0 

0 

0 

0 

0 

FGB_PDGF_Troubleshooting 

50 

30 

30 

0 

0 

0 

0 

0 

0 

0 

J  E  M_E  F_F  wd_Ca  m  e  ra 

45 

60 

60 

0 

0 

0 

0 

0 

0 

0 

MLM_Ethernet_Cable_lnstall 

40 

65 

65 

0 

0 

0 

0 

0 

0 

0 

Table  20.  Task  Data 
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Task 

Initial  Location 

Final  Location 

Egress_Setup 

Airlock 

Airlock 

MBS_Mast_CLPA_RR 

Airlock 

Airlock 

MTRAJnstall 

Airlock 

Airlock 

MISSE_8_Retrieve 

Airlock 

Airlock 

Node3_Fwd_Aft_CBM_Prep 

Node3 

Node3 

Route_1553_Cable 

Airlock 

Airlock 

Remove_MBSU_MLI 

Airlock 

Airlock 

Cleanupjngress 

Airlock 

Airlock 

Zl_Jumper_Route_lnstall 

Airlock 

Airlock 

FGB_PDGF_Troubleshooting 

FGB 

FGB 

JEM_EF_Fwd_Camera 

Airlock 

Airlock 

MLM_Ethernet_Cable_lnstall 

Airlock 

Airlock 

Table  2 1 .  Task  Locations 


Predecessor 

Successor 

Egress_Setup 

Cleanupjngress 

Table  22.  Precedence  Relationships 


Airlock 

ELC2 

MT 

Node3 

Z1 

JEM 

FGB 

Nodel 

Airlock 

0 

12 

8 

5 

8 

15 

10 

5 

ELC2 

12 

0 

8 

17 

16 

20 

22 

17 

MT 

8 

8 

0 

13 

16 

10 

18 

13 

Node3 

5 

17 

1 

0 

5 

15 

5 

2 

Z1 

8 

16 

16 

5 

0 

20 

8 

5 

JEM 

15 

20 

10 

15 

20 

0 

20 

20 

FGB 

10 

22 

18 

5 

8 

20 

0 

5 

Nodel 

5 

17 

13 

2 

5 

20 

5 

0 

Table  23.  Translation  Times 
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1st  Sunrise  @  0:30  PET 

1st  Sunrise  @  1:00  PET 

1st  Sunrise  @  1:30  PET 

tmin 

tmax 

tmin 

tmax 

tmin 

tmax 

wl 

Egress_Setup 

0 

30 

0 

30 

0 

30 

wl 

MT  RAJ  n  stall 

0 

240 

0 

240 

0 

240 

wl 

MISSE_8_Retrieve 

30 

115 

60 

145 

1 

86 

w2 

MISSE_8_Retrieve 

120 

205 

150 

235 

90 

175 

w3 

MISSE_8_Retrieve 

210 

295 

240 

325 

180 

265 

w4 

MISSE_8_Retrieve 

300 

385 

330 

390 

270 

355 

Table  24.  Task  Time  Windows  (for  three  day/night  phasing  cases) 
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